Methods and systems for determining and selling outcomes for roulette games to be viewed remotely

ABSTRACT

In accordance with some embodiments, a plurality of outcomes are generated and used to create a video presentation of representative outcomes (e.g., for a roulette game) for one or more players. The video presentation is recorded onto a tangible medium (e.g., DVD or CD-ROM) or otherwise provided to one or more players (e.g., a player may access the video presentation online). This allows one or more players to purchase a video presentation of (e.g., predetermined) outcomes in a jurisdiction in which gambling is legal yet view the presentation at the player&#39;s convenience (e.g., from any jurisdiction and at any time). At least one player who is associated with such a video presentation may subsequently redeem it for a redemption value associated therewith.

The present application claims the benefit of U.S. ProvisionalApplication Ser. No. 60/666,393, filed Mar. 29, 2005, and entitledMETHODS, SYSTEMS AND APPARATUS FOR PROVIDING GAMBLING RESULTS THAT MAYBE VIEWED REMOTELY. The entirety of the above-identified application isincorporated by reference herein for all purposes.

The present application claims the benefit of U.S. ProvisionalApplication Ser. No. 60/685,604, filed May 27, 2005, and entitledMETHODS, SYSTEMS AND APPARATUS FOR PROVIDING GAMBLING RESULTS THAT MAYBE VIEWED REMOTELY. The entirety of the above-identified application isincorporated by reference herein for all purposes.

A. BRIEF DESCRIPTION OF THE FIGURES

Various embodiments of the present invention are described herein withreference to the accompanying drawings. In the drawings, like referencenumerals indicate identical or functionally similar elements. Theleftmost digit(s) of a reference numeral typically identifies the figurein which the reference numeral first appears. As will be understood bythose skilled in the art, the drawings and accompanying descriptionspresented herein indicate some exemplary arrangements for storedrepresentations of information. A number of other arrangements may beemployed besides the tables shown. Similarly, the illustrated entriesrepresent exemplary information, but those skilled in the art willunderstand that the number and content of the entries can be differentfrom those illustrated herein. A brief description of the drawingsfollows.

FIG. 1 is a flowchart of an example process according to someembodiments described herein.

FIG. 2 is a block diagram of an example “life cycle” of a DVD accordingto some embodiments described herein.

FIG. 3 is a block diagram of an example system in accordance with someembodiments described herein.

FIG. 4 is a block diagram of an example casino server (CS) in accordancewith some embodiments described herein.

FIG. 5 is a block diagram of an example assembly system (AS) inaccordance with some embodiments described herein.

FIG. 6 is a block diagram of an example gaming device (GD) in accordancewith some embodiments described herein.

FIG. 7A is a table illustrating an example record of an example sessiondatabase in accordance with some embodiments described herein.

FIG. 7B is a table illustrating an example record of another examplesession database in accordance with some embodiments described herein.

FIG. 8 is a table illustrating an example GD database in accordance withsome embodiments described herein.

FIG. 9 is a table illustrating an example active sessions database inaccordance with some embodiments described herein.

FIG. 10 is a table illustrating an example available DVDs database inaccordance with some embodiments described herein.

FIG. 11A is a table illustrating an example record of an example mediafile database in accordance with some embodiments described herein.

FIG. 11B is a table illustrating an example record of another examplemedia file database in accordance with some embodiments describedherein.

FIG. 12 is a table illustrating an example record of an example sessionmedia file database in accordance with some embodiments describedherein.

FIG. 13A-13C are a table illustrating an example embodiment of a DVDproduction queue database in accordance with some embodiments describedherein.

FIG. 14 is an example record of an example outcome sets database inaccordance with some embodiments described herein.

FIG. 15 is an example of a probability database in accordance with someembodiments described herein.

FIG. 16 is an example of a payout database in accordance with someembodiments described herein.

FIG. 17 is a flowchart of an example process for determining a set ofoutcomes and/or payouts to be represented in a video presentation, inaccordance with some embodiments described herein.

FIG. 18 is a flowchart of an example process for determining a set ofmedia files for a DVD, in accordance with some embodiments describedherein.

FIG. 19 is a flowchart of an example process for making a DVD availablefor purchase, in accordance with some embodiments described herein.

FIG. 20 is a flowchart of an example process for determining processingan order for a DVD, in accordance with some embodiments describedherein.

FIGS. 21A and 21B are a flowchart of an example process for creating aDVD, in accordance with some embodiments described herein.

FIG. 22 is a flowchart of an example process for storing an indicationof a sale of a DVD, in accordance with some embodiments describedherein.

FIG. 23 is an example of a receipt that may be output upon a purchase ofa DVD, in accordance with some embodiments described herein.

FIG. 24 is an example of a receipt that may be output upon a purchase ofa DVD, in accordance with some embodiments described herein.

FIG. 25 is an example of multiple receipts that may be output upon apurchase of a DVD, in accordance with some embodiments described herein.

FIG. 26 is an example of another receipt that may be output upon apurchase of a DVD, in accordance with some embodiments described herein.

FIG. 27 is a flowchart of an example process for providing a paymentcorresponding to a DVD redemption value, in accordance with someembodiments described herein.

FIG. 28 is an example presentation that may be output in accordance withsome embodiments related to roulette games.

FIG. 29 includes several examples of a ticket that may be output inaccordance with some embodiments described herein.

FIG. 30 is an example screen of information that may be output inaccordance with some embodiments described herein.

FIG. 31 is an example record of a database that may store an indicationof payouts determined during a session that may be output in accordancewith some embodiments described herein.

B. DETAILED DESCRIPTION OF EMBODIMENTS

1. Introduction to Some Embodiments

In accordance with one or more embodiments, a method provides fordetermining a plurality of outcomes of a wagering game (e.g., a roulettegame) and storing an indication of the plurality of outcomes.

The method optionally further provides for associating at least one ofthe plurality of outcomes with a first player and optionally furtherprovides for associating at least one of the plurality of outcomes witha second player.

The method further provides for selling, after the last of the pluralityof outcomes has been generated, the plurality of outcomes to a purchaser(e.g., a player) in exchange for a price or other value. The pluralityof outcomes may be provided to a player, for example, by being recordedon a tangible medium (e.g., a DVD), the tangible medium being providedto the player. In another embodiment, the plurality of outcomes may beprovided to the player by being stored on a server device and providingthe player access to the server device (e.g., such that the player mayaccess the outcomes via the Internet).

A purchaser, as the term is used herein unless indicated otherwise, mayrefer to any person or other entity providing value in exchange for aplurality of outcomes. A purchaser may refer to, for example, a player,a customer who intends to give the plurality of outcomes to another as agift, a retailer, or a casino. For convenience, several exemplaryembodiments are described in this disclosure with respect to a player;it will be understood that any such embodiments may be applicable toother types of purchasers.

A player, as the term is used herein unless indicated otherwise, mayrefer to an actual person who is a player (e.g., one who might purchaseor otherwise receive a purchased plurality of outcomes and/or one whomay redeem value associated with a set of purchased outcomes), to asimulated player (e.g., a “RED” player represented or identified on agame disc in association with a particular set of game results oroutcomes), and/or to a simulated player associated with an actual personor player (e.g., for purposes related to purchasing outcomes, gameplay/viewing of purchased outcomes, and/or redemption of value).

An outcome, as the term is used herein unless indicated otherwise,refers to a result of a game play, which may be indicated by a payout(i.e., a prize or benefit to be provided as a result of the game play)and/or one or more indicia representative of the result. For example, anoutcome may comprise the set of indicia (or payout correspondingthereto) that may be displayed along a payline of a reeled slot machine.In another example, an outcome may comprise a roulette number that is aresult of a roulette spin. In some embodiments, more than one set ofindicia may represent the same result or outcome.

In accordance with one or more embodiments, a method provides forcausing a plurality of actual outcomes to be generated on a computingdevice operable to simulate play of a wagering game, in which generatinga first actual outcome of the plurality of actual outcomes is based on apreviously generated second actual outcome of the plurality of actualoutcomes, and in which the first actual outcome is associated with afirst player and the second actual outcome is associated with a secondplayer. In one embodiment, the method further provides for determiningdata indicative of the plurality of actual outcomes; determining, basedon the data, a plurality of representations (e.g., images and/or othervideo and/or audio), each representation representing an outcome to bestored on a tangible medium, each representation thereby comprising arepresentative outcome; causing the plurality of representative outcomesto be stored on a tangible medium; and making the tangible mediumavailable for sale.

In one embodiment, an outcome may be represented via indicia of a mediafile. A media file may comprise graphical and/or audio data. Thegraphical data may comprise a still or animated image of one or moreindicia. In some embodiments, more than one media file may correspond toa particular outcome or result. For example, more than one media filemay correspond to an outcome that results in zero credits being added toa credit meter balance.

A game, as the term is used herein unless indicated otherwise, comprisesa wagering activity conducted in accordance with a particular set ofrules via which a prize or benefit may be won in exchange forconsideration.

A game play, as the term is used herein unless indicated otherwise,refers to a single instance or round of a game. A game play may resultin a single outcome (e.g., set of indicia and corresponding payout, ifany).

A type of game, as the term is used herein unless indicated otherwise,refers to a category of games that share one or more characteristics.

In accordance with one or more embodiments, a method provides forcausing a plurality of actual outcomes to be generated on a gamingdevice operable to facilitate a wagering game and determining dataindicative of the plurality of actual outcomes. The method furtherprovides for determining, based on the data, a plurality ofrepresentations (e.g., images and/or other video and/or audio), eachrepresentation representing an outcome to be stored on a tangiblemedium, each representation thereby comprising a representative outcome.The method further provides for causing the plurality of representativeoutcomes be stored on a tangible medium and making the tangible mediumavailable for sale.

An actual outcome, as the term is used herein unless indicatedotherwise, is an outcome directly determined by a GD. For example, anactual outcome may comprise the random number determined by the randomnumber generator of a GD, the particular set of indicia that correspondsto the random number based on the probability table used by the GDand/or the payout that corresponds to the random number.

A representative outcome, as the term is used herein unless indicatedotherwise, is an indication of an actual outcome, the representationbeing determined based on the actual outcome and, in some embodiments,by a device other than a GD. For example, an AS may determine, based ona random number determined by a GD, a media file to represent the actualoutcome determined by the GD. The media file may comprise a graphicalrepresentation of a set of indicia and this set of indicia may be arepresentative outcome corresponding to the actual outcome determined bythe GD.

It should be understood that, for a particular set of outcomes, the setof actual outcomes may correspond to the same sum of payouts as does thecorresponding set of representative outcomes.

In some embodiments, the outcome in a set of actual outcomes thatcorresponds to a set of representative outcomes may (i) differ innumber; (ii) differ in order (i.e., the actual outcomes may have beengenerated in a first order while the representative outcomes may bepresented in a second order); and/or (iii) differ in indicia or form ofindicia.

A session, as the term is used herein unless indicated otherwise, is aplurality of game plays conducted for the purpose of determining aplurality of outcomes to be sold (e.g., to a player or other type ofpurchaser). For example, a session may refer to a plurality of gameplays executed by a GD, based on which plurality of game plays (e.g.,representative outcomes and/or actual outcomes) a video representationof outcomes is created and recorded onto a DVD or other tangible medium,or based on which plurality of game plays the video presentation isotherwise made available to a player. A session may be completed over aplurality of distinct time periods (e.g., some of the outcomescomprising the session may be generated at a first date and/or timewhile more of the outcomes comprising the session may be generated at asecond date and/or time). Further, a session may be executed on aplurality of GDs (e.g., simultaneously or in parallel fashion and/or atvarious times). A session may be deemed to be completed once an endevent defining the end of the session has occurred (e.g., a predefinednumber of outcomes has been generated, outcomes have been generated fora predefined period of time, a credit meter balance has reached apredefined value, etc.). In some embodiments, a session may be deemed tobe completed once one of a plurality of possible end events occurs,whichever end event occurs first.

According to some embodiments, a session may refer to a plurality ofgame plays conducted for the purpose of determining a plurality ofoutcomes, in which the plurality of (representative and/or actual)outcomes may be associated with, or correspond to, one or more (realand/or simulated) players. In one example, one or more players mayrequest a session that is executed to determine a plurality of outcomesthat are then sold to the player(s). In another example, a videorepresentation of outcomes is created that includes at least one outcomecorresponding to one simulated and/or actual player, and at least oneoutcome corresponding to a different simulated and/or actual player.

It should be noted that although the terms DVD and game disc are usedherein to refer to a tangible medium on which an indication of aplurality of outcomes may be recorded and which tangible medium may besold to a player, these terms are used for purposes of brevity only andshould not be taken in a limiting fashion. All references to DVD or gamedisc likewise include any other form of tangible medium that may beappropriate and practicable for recording an indication of outcomes(e.g., a video presentation) for subsequent remote viewing by a player.For example, paper (e.g., a flip-through book), a CD-ROM, a VHS tape,flash memory, a memory stick, a digital video tape, an MP3 file, or anyother tangible medium for recording information may be used. Further,practicable variations of such media are contemplated (e.g., DVD-R,CD-R, CD-RW, etc.). It should be understood that the use of the term DVDor game disc is a reference to any and all such tangible mediums.

In accordance with one or more embodiments, a method provides forreceiving, from a player, a request for a payout corresponding to aplurality of outcomes previously sold to the player, wherein the payoutis a function of a sum of payouts of the plurality of outcomes, andwherein the plurality of outcomes had been sold to the player as apackage without providing to the player an indication of the payout. Apayout corresponding to a DVD that is a function of a sum of payouts ofthe plurality of outcomes or an aggregate of the payouts may be, in someembodiments, the “redemption value” of the DVD or other medium via whichsession information is remotely viewable. The method further providesfor verifying a legitimate purchase of the plurality of outcomes by theplayer, verifying the payout and providing the payout to the player. Insome embodiments, the method may further provide for storing anindication of the payout having been provided to the player and/orverifying that the payout has not previously been provided to theplayer.

The term “redemption value” is used herein to refer to a monetary amountor prize that a player may redeem a purchased DVD for. This term refers,unless indicated otherwise, to a value that is a function of a sum ofpayouts (which may be a single payout in some instances), the payoutsbeing the payouts corresponding to the outcomes represented on the DVD.The value may be, for example, a function of (i) the starting creditmeter balance at the beginning of the session executed to determine theoutcomes represented on the DVD, (ii) a sum of wagers posted for thegame plays comprising the session; and (iii) the payouts won as a resultof game plays comprising the session. For example, assuming a session isexecuted with a starting balance of $5.00, twenty game plays areexecuted during the session at a wager of $0.25 per game play, and threeof these game plays result in a payout greater than zero (the firstpayout being $4.00, the second payout being $12.00 and the third payoutbeing $3.00), the ending credit meter balance at the end of the sessionis $19.00. Thus, in some embodiments the redemption value of the DVD maybe the ending credit meter balance, which is $19.00 in the aboveexample. In other words, a player who purchases this DVD for $20.00 mayredeem the DVD for $19.00.

In accordance with one or more embodiments, a method provides forselling a plurality of outcomes as a package, wherein the plurality ofoutcomes is based on at least one random number result generated by agaming device operable to facilitate a wagering game, and wherein theselling occurs after the at least one result has been generated andprior to a payout for any outcome of the plurality of outcomes havingbeen provided to a player.

In accordance with some embodiments, provided are apparatus, systems andmethods for enabling casino patrons to view gambling results remotely.In one or more embodiments, a player may purchase a session of gameplays from a casino. Using a gaming device located within the casino,the session may then be executed on the player's behalf according toparameters of the session (e.g., number of game plays, wager per gameplay, payout combinations active, game, gaming device or type of gamingdevice, etc.). For example, a slot machine may be configured to rapidlygenerate a plurality of outcomes on the player's behalf. In someembodiments, files representing the generated outcomes may then bestored on media (e.g., a CD-ROM or DVD). The player may then remotelyview the previously generated outcomes at a later time (e.g., using oneor more devices such as home computers, televisions, DVD players, PDAs,cellular phones, and so on), so as to experience wins and lossesassociated with the session.

Some embodiments will now be described with reference to FIGS. 1-31.

Referring now to FIG. 1, illustrated therein is a flowchart of anexample process 100 that may be performed in accordance with one or moreembodiments. It should be noted that, as is true for all processesdescribed herein, process 100 may, in some embodiments, be performed bya variety of devices and/or persons. For example, one or more of thesteps described may be performed by a GD (described in detail withreference to FIG. 6), one or more of the steps may be performed by a CS(described in detail with reference to FIG. 4), one or more of the stepsmay be performed by a AS (described in detail with reference to FIG. 5),one or more steps may be performed by another device (e.g., CPD, POS, oranother device) and/or one or more of the steps may be performed by aperson (e.g., a casino attendant or player). Further, the steps may beperformed in an order different from that described. Further still,additional or different steps may be included and some steps may beomitted or modified, as appropriate and/or practicable.

In step 105, a plurality of outcomes of a slot machine game isdetermined. Determining the plurality of outcomes may comprise, forexample, determining a plurality of actual outcomes. For example, ifstep 105 is being performed by a GD, determining a plurality of outcomesmay comprise generating a plurality of random numbers, each randomnumber comprising an outcome. If step 105 is being performed by anotherdevice (e.g., CS 305 or AS 310, both described below with respect toFIG. 3), step 105 may comprise determining an indication of a pluralityof actual outcomes generated by a GD. For example, such an indicationmay be received via an electronic transmission from a device (e.g., a GDmay transmit such an indication to a CS and/or AS via a networkconnection). In another example, such an indication may be received viaa printed document (e.g., a session results ticket, described below(particularly with reference to FIG. 29)) may include a bar code orother encoded information readable by a CS and/or AS, for determiningthe indication.

An indication of the plurality of outcomes may comprise, for example,one or more of the following information:

(i) a sum of payouts won as a result of the plurality of outcomes;

(ii) an ending credit meter balance at the end of a session comprisingthe plurality of outcomes;

(iii) a set of indicia representative of one of the plurality ofoutcomes (e.g., a result of a roulette spin, a plurality of symbolsrepresenting a hand of video poker, a plurality of symbols that may bedisplayed along a payline of a reeled slot machine, etc.);

(iv) a game for which the plurality of outcomes was determined;

(v) a sum of wagers posted for the plurality of outcomes;

(vi) a price of the session;

(vii) a beginning credit meter balance at the beginning of a sessioncomprising the plurality of outcomes;

(viii) a player associated with at least one of the plurality ofoutcomes (e.g., in embodiments in which a player requests a sessionprior to it being executed, or in embodiments in which a first player isassociated with a first subset of the plurality of outcomes and adifferent player is associated with a different subset of the pluralityof outcomes);

(ix) a casino attendant associated with the plurality of outcomes (e.g.,the casino attendant who authorized, supervised and/or executed thesession comprising the plurality of outcomes);

(x) a unique identifier of a session comprising the plurality ofoutcomes (e.g., such that information regarding the plurality ofoutcomes may be determined by accessing an appropriate database based onthe unique identifier);

(xi) a unique identifier corresponding to an outcome of the plurality ofoutcomes;

(xii) an identifier of a media file corresponding to an outcome of theplurality of outcomes;

(xiii) a time and/or date at which an outcome of the plurality ofoutcomes was generated;

(xiv) a gaming device on which the plurality of outcomes was generated;

(xv) a type of gaming device on which the plurality of outcomes wasgenerated;

(xvi) an activation ID used to determine sale of a session; and

(xvii) a redemption ID used to determine redemption of a session.

As described herein, in some embodiments determining an indication of aplurality of outcomes may comprise determining one or more playerscorresponding to the plurality of outcomes. In some embodiments, a firstplayer may be associated with a subset of the plurality of outcomes, anda second player may be associated with a different subset of theplurality of outcomes. In some embodiments, a player may be associatedwith more than one subset. Some methods and systems provide forassociating at least one of the plurality of outcomes with a firstplayer and for associating at least one of the plurality of outcomeswith a second player.

In some embodiments, determining a plurality of outcomes may comprisedetermining a plurality of representative outcomes. For example, if step105 is being performed by an AS, determining a plurality of outcomes maycomprise determining an indication of a plurality of outcomes (e.g., thepayouts corresponding to each outcome of the plurality of outcomes, asum of payouts corresponding to the plurality of outcomes, or any otherof the information listed above) and selecting representative outcomesto represent a plurality of actual outcomes generated by a GD.

It should be understood that in some embodiments a plurality of outcomesare generated (e.g., a session of game plays is executed to determine aplurality of outcomes to be recorded on a DVD) prior to any playerexpressing any interest in purchasing the plurality of outcomes. Forexample, an entity (e.g., casino, GD manufacturer and/or other entity)may create (or cause to be created) DVDs, each DVD having recordedtherein a video representation of a plurality of outcomes, and place thecreated DVDs on a casino floor for purchase by players.

In some embodiments, a player may purchase, request or otherwise agreeto a session (e.g., the player may request or order a DVD of outcomes tobe created on behalf of the player). In such embodiments, methods forproviding gaming contracts and/or flat rate gaming sessions may beapplied to embodiments described herein. Many such methods are describedin commonly-owned, co-pending U.S. Provisional Application No.60/627,670, filed Nov. 12, 2004, entitled “GAMING DEVICE OFFERING A FLATRATE PLAY SESSION AND METHODS THEREOF”; U.S. Provisional Application No.60/600,211, filed Aug. 10, 2004, entitled “SYSTEMS, METHODS ANDAPPARATUS FOR ADMINISTERING GAMING CONTRACTS”; U.S. application Ser. No.10/636,520, filed Aug. 7, 2003, entitled “SYSTEM AND METHOD FORCOMMUNICATING GAME SESSION INFORMATION”; U.S. application Ser. No.10/635,986, filed Aug. 7, 2003, entitled “SYSTEM AND METHOD FOR REMOTEAUTOMATED PLAY OF GAMING DEVICES”; U.S. patent application Ser. No.10/001,089, filed Nov. 2, 2001, entitled “GAME MACHINE FOR A FLAT RATEPLAY SESSION AND METHOD OF OPERATING SAME”; and U.S. Pat. No. 6,077,163,filed Jun. 23, 1997, entitled “GAMING DEVICE FOR A FLAT RATE PLAYSESSION AND METHOD OF OPERATING SAME”; the entirety of each areincorporated herein by reference for all purposes.

For example, a player may request a session by (i) actuating an inputdevice of a gaming device, kiosk or other device described herein (e.g.,the player actuates an icon of a touch-sensitive display screenadvertising “Purchase a DVD” or other similar text), (ii) indicatingsuch a desire verbally to a casino representative (e.g., in person orover the phone), (iii) filling out and submitting forms or otherpaperwork, and so on.

In some embodiments, a session may comprise a remote session, wherein aplayer need not be present to execute one or more game plays associatedwith the session (e.g., a player purchases 1,000 spins of a slot machinefor a flat price of $15). For example, after receiving a request toexecute such a remote session, a casino attendant may execute (or causeto be executed) the session on the player's behalf using a GD on casinopremises. The player may then remotely view data associated with thesession (e.g., representative outcomes determined based on the resultsof the session) at a later time without necessarily gambling outside ofcasino premises (e.g., the player simply views results which havealready been generated in a legal jurisdiction). Those familiar with thecurrent legal framework concerning gambling in the Unites States willappreciate the advantages of such a system (e.g., it allows players toplace legal slot machine bets and watch the results from home).

Irrespective of whether a session is executed on behalf of a playerafter the player requests the session or whether the session is executedprior to any player expressing an interest in the session, severalparameters and values thereof may be associated with (e.g., define) asession. For example, a session may be defined by one or moreparameters, including but not limited to

(i) a number of players with whom the session is associated (e.g., thesession will be used to generate a video representation that simulatesgame play by four different players);

(ii) a game and/or type of game for which the game plays of the sessionare to be conducted (e.g., “Big Texas Oil,” keno, roulette, “CrazyTriple Joker Poker,” 5-reeled slot machine game) that may be helpful indetermining how the session(s) should be executed (e.g., for amultiplayer bingo game, a device operable to simulate multiplayer playmay be required);

(iii) an average, minimum, maximum or specified wager amount per gameplay (e.g., a session parameter specifies that $0.25 will be wagered pergame play);

(iv) one or more gaming devices on which game play may occur (e.g., anyvideo slot machine, any video poker machine except “Crazy Triple JokerPoker,” any “Big Texas Oil” machine, the “Big Texas Oil” machine in RoomZ numbered GD-BTO-0012, and so on);

(v) active pay combinations and/or a payout schedule to be used duringthe execution of game plays comprising the session (e.g., a sessionparameter specifies that an outcome of “BAR-BAR-BAR” pays 1,500 coins,and so on);

(vi) a date and/or a time (e.g., of day) during which the session may beexecuted (e.g., between 6 and 10 a.m. on Jan. 1, 2006);

(vii) a refund rate or amount payable to a player (e.g., the player willreceive a refund of 50% of net losses incurred due to the session);

(viii) a manner in which game play or the game results thereof will bemade available to players (e.g., the casino will provide a DVDcomprising video renderings of outcomes generated previously by a gamingdevice on the casino floor; the casino will enable the player to playone or more gaming devices on the casino floor in person, such that theplayer may be present when game play occurs; the casino will provide acode which a player may later use online to access video renderings ofoutcomes previously generated by a gaming device on the casino floor;etc.);

(ix) a price, which may represent, for example, how much the player paysin exchange for gaining access to the plurality of outcomes determinedas a result of a session (e.g., how much a player pays for a DVD onwhich a video representation of the outcomes is recorded);

(x) a session duration, which may be defined, for example, in time,number of game plays (e.g., the session ends after two hours or thesession ends after 1,000 game plays) or another ending event (e.g., thesession ends when the credit meter balance reaches zero or anotherpredetermined value); and

(xi) other stipulations related to game play (e.g., a number of paylinesof a slot machine game that should be bet on, a strategy forholding/discarding cards in a poker game, wager per payline, etc.).

In embodiments in which a session is executed on behalf of a particularplayer, a player may select, purchase or otherwise agree to suchparameters when requesting a session (e.g., the player uses an inputdevice of a GD to select certain parameters, the player selects certainparameters by checking off appropriately labeled boxes of a paper form,the player verbally instructs a casino attendant that he agrees tocertain parameters, and so on). It should be noted that, as described inthe above-referenced commonly owned patents and patent applications, theparameters a player selects may have an affect on the session price(e.g., generally, more game plays, higher wager amounts and more activepay combinations may require higher session prices).

In this manner, a player may request that a session characterized bycertain parameters be executed. For example, a player may provide asession price of $15, and in turn, a casino may agree to provide 1,000game plays of a particular GD at a wager amount of 25¢ per game play.Further, a manner in which game play or game results may be provided maybe stipulated (e.g., the casino will provide a DVD comprising a videopresentation of outcomes generated by a GD on the casino floor). In someembodiments, additional parameters may define a session and may be setby a player, casino and/or other entity. For example, a time duringwhich game play may occur may be stipulated (e.g., game play will begenerated on the player's behalf at any time deemed appropriate by thecasino before Thursday night). Still further, a time/date when gameresults may be provided to a player may be stipulated (e.g., the playeragrees to allow 1-2 weeks for the delivery of a DVD comprising a videopresentation of outcomes generated by a GD on the casino floor).Accordingly, a system of the present invention may receive a request toexecute a session, such as a remote session, wherein a GD may beconfigured to execute a plurality of game plays on the player's behalfwhile the player is not present, with the results of said game playsbeing provided to a player in a manner such that the player may view theresults remotely.

It should be noted that, in some embodiments, when requesting that asession be executed, a player may provide various contact information(e.g., postal address, phone number, e-mail address, and so on), suchthat players may be provided with the results of the session via thecontact information (e.g., a code my be e-mailed to the e-mail address,the code for accessing the results online or a DVD may be mailed to thepostal address, etc.).

In embodiments in which a session is executed prior to any playerexpressing an interest in the session (e.g., embodiments in which DVDsof sessions are massively produced and made available for purchase), anentity such as a casino, GD manufacturer and/or other entity may definethe parameters and values thereof defining a session. For example, suchan entity may program a GD to execute 1000 sessions, each session beingdefined by a set of particular parameters (and values thereof).

In some embodiments, step 105 (or another or additional step) maycomprise storing an indication of parameters defining a session inassociation with the session (e.g., in association with a unique sessionidentifier in a record of an appropriate database). In one or moreembodiments, a unique session identifier (e.g., numeric or alphanumericidentification code) may be associated with each session that isexecuted or that is scheduled for execution. In some embodiments, suchinformation may be stored electronically. For example, variousparameters and values thereof may be stored in a record of a database,each record defining a session executed, available for execution and/orscheduled to be executed. It should be noted that such a database may bestored in a variety of locations, including but not limited to within aGD and/or CS. Alternately or additionally, a physical, non-electronicrecord of such session parameters may be kept. For example, if a playerhas filled out a paper form indicating various session parameters, theform may be filed away or saved such that it may later be used whenexecuting the session. In another example, both a physical and anelectronic record may be kept (e.g., a casino attendant may enterdesired session parameters and values thereof using a computing devicesuch that they are recorded in a database, then use a softwareapplication of the computing device to print a physical piece of paperindicating the desired parameters and values thereof).

In summary, irrespective of whether a session is prompted by a requestfrom a player or is produced without a player request (e.g., as part ofa mass production process), step 105 comprises determining a pluralityof outcomes comprising the session. The step may comprise one or moresubroutines, such as a subroutine for (i) determining one or moreparameters (and values thereof) defining a session comprising theplurality of outcomes; (ii) generating the plurality of outcomes; (iii)determining an indication of the plurality of outcomes (which maycomprise determining an indication of a plurality of actual outcomesand/or determining an indication of a plurality of representativeoutcomes); (iv) decoding or interpreting the indication to determine aplurality of representative outcomes; and/or (v) selecting a pluralityof media files, each media file corresponding to an outcome of theplurality of outcomes. Such subroutines and others are described indetail below, particularly with respect to FIGS. 19-26.

It should be noted that when reference is made to an “outcome” herein,such reference may refer to an actual outcome and/or a representativeoutcome. In step 110, an indication of the plurality of outcomes isstored. Storing an indication of the outcomes may comprise, for example,one or more of (i) storing an indication of the outcomes in a memory(e.g., a mass storage device) of a device such as a GD, CS or AS; (ii)recording (or causing to be recorded) an indication of the plurality ofoutcomes on a DVD; and (iii) printing (or causing to be printed) anindication of the plurality of outcomes on a document (e.g., a sessionresults ticket). It should be understood that an indication of aplurality of outcomes may comprise any and all of the informationdescribed with respect to step 105.

For example, storing an indication of outcomes may comprise a GDtransmitting an indication of the plurality of outcomes to a CS and theCS in turn transmitting the indication (or another indication based onthe indication received from the GD) to an AS. Step 110 may furthercomprise the AS creating a video representation of the plurality ofoutcomes (e.g., by selecting a plurality of media files, each media filecorresponding to one of the plurality of outcomes) and recording themedia files onto a DVD.

In one embodiment, storing an indication of the plurality of outcomesmay comprise storing a representative outcome for each of the pluralityof outcomes. In one embodiment, storing an indication of the pluralityof outcomes may comprise recording a plurality of media files onto aDVD, each media file corresponding to one outcome of the plurality ofoutcomes or, alternatively, combining the plurality of media files intoa single media file and storing that to the DVD. In one embodiment,storing an indication of the plurality of outcomes may comprise storingan indication of each outcome of the plurality of outcomes.

In one embodiment, storing an indication of the plurality of outcomesmay comprise populating a record of an appropriate database (e.g., withan indication of each outcome of the plurality of outcomes) forsubsequent creation of a video presentation of the plurality ofoutcomes. For example, a first program of a device may receive anindication of the plurality of outcomes and determine particularrepresentative outcomes (e.g., particular payouts and the order thereof,particular media files and the order thereof, and/or particular sets ofindicia, each set corresponding to an outcome of the plurality ofoutcomes). This first program may cause the determined information to bestored in a database. A second program may then create a videorepresentation of the outcomes. A third program may then cause the videopresentation to be recorded onto a DVD. Of course, a single program maybe used or the first, second and third program may be combined in anymanner practicable and desirable. Further, the first, second and thirdprogram may each be performed by different devices or the same device,and the devices may or may not be geographically proximate to eachother, depending on what is practicable and desirable.

In one or more embodiments, step 110 may comprise storing a result of asession (e.g., an indication of outcomes determined for the session) inan electronic manner. For example, as described, data associated with asession may be stored electronically in a session database (e.g., asession database 425, an example record of which is illustrated in FIGS.7A and 7B). In some embodiments, session data may be stored on a smartcard (e.g., a smart card inserted into a reader device in communicationwith a GD) or another portable storage medium.

Storage and/or transmission of an indication of the plurality ofoutcomes may occur at any time. For example, some indication of theplurality of outcomes may be stored and/or transmitted prior to theexecution of a session corresponding to the plurality of outcomes (e.g.,an indication of the session identifier and/or parameters of the sessionmay be stored in a record of a database upon the session being scheduledand/or ordered). In another example, some indication of the plurality ofoutcomes may be stored and/or transmitted during or after the executionof a session (e.g., game play results are individually stored as theyare generated; game play results are stored in RAM while they are beinggenerated, then written to ROM and erased from RAM; and so on). Thus,step 110 may comprise transmitting and/or storing an indication of aplurality of outcomes electronically to a memory.

It should be appreciated that such data may be stored electronically ina variety of formats. For example, as depicted by FIGS. 7A and 7B,various data may be stored as records of a database entry associatedwith a session identifier. For example, in one embodiment, a databasemay store text indicating any or all of a wager amount, outcome, outcomeidentifier and payout amount associated with a particular game playnumber (e.g., the first game play of a session is game play “1”). Insome embodiments, an indication of a plurality of outcomes or other dataassociated with a session may be stored electronically in an encodedfashion. For example, a bit function representing an outcome may bestored in a database (e.g., “BAR-LEMON-CHERRY” is stored as0129-2938-3847, each four-digit sequence representing a particularsymbol).

In some embodiments, storing an indication of the plurality of outcomesmay comprise accessing a media file database (e.g., an exampleembodiment of which is depicted in FIGS. 11A and 11B, respectively) todetermine a media file (e.g., a media file associated with a result of agame play), and then storing an indication of a game play number alongwith an associated media file.

Alternately or additionally, storing an indication of the plurality ofoutcomes may comprise outputting the indication in some physical,non-electronic fashion. For example, in some embodiments, a GD mayactuate a printer device to print a bar code encoding the indication ofthe plurality of outcomes (e.g., an indication of a session result). Forexample, a GD may print upon a conventionally sized TITO ticket ahigh-density barcode encoding an indication of the plurality of outcomesassociated with an executed session. For example, text, numerals orother symbols stored within a session database (e.g., a series ofoutcome identifiers) may be encoded such that they are representedgraphically by a barcode such as a high-density barcode. Various methodsof encoding such text and/or numerals graphically using a high-densitybarcode are contemplated. In further embodiments, encoding an indicationof the plurality of outcomes as a printed barcode may comprise accessinga media file database (e.g., see FIG. 12) to determine a media fileassociated with an outcome, and then encoding a game play number alongwith an associated media file or indication of an associated media file(e.g., an identifier that uniquely identifies a media file).

Accordingly, in various embodiments, storing an indication of theplurality of outcomes may comprise outputting and/or storing theindication in an electronic and/or physical fashion. As described, insome embodiments, a session may have been executed without interactionfrom a user (e.g., agent), as an electronic signal instructing a GD toexecute a session defined by certain parameters and values thereof maybe sent by a separate device. Accordingly, in some embodiments, a person(e.g., a casino attendant or player) may approach a GD and access orattain an indication of the plurality of outcomes corresponding to thesession. For example, a casino attendant may be dispatched to collect acashout ticket, video ticket and/or session results ticket from a GD. Inanother embodiment, a casino attendant may be dispatched with a smartcard or other portable memory device (e.g., a CPD). The casino attendantmay insert the smart card into a reader device of a GD, and theindication of the plurality of outcomes may be transferred or copiedfrom a memory of the GD to a memory of the smart card or other portablememory device. For example, in one embodiment, an indication of theplurality of outcomes may be stored temporarily in GD memory until it isretrieved by a casino attendant or player (and, e.g., transferred to asmart card) and/or transmitted to another device.

In step 115, it is determined whether the last of the plurality ofoutcomes has been generated. In some embodiments, a session is notconsidered to be completed (and thus the results of the session notready for sale or other provision to a player) until the last of theoutcomes comprising the session has been generated. Accordingly, it maybe determined whether the last of the outcomes has been generated. Forexample, a parameter of a session defining the duration of the sessionmay be determined (e.g., a number of outcomes) and compared to the datacomprising the indication of the plurality of outcomes. If the dataindicates that the number of outcomes defined by the parameter is thesame as the number of outcomes indicated by the indication, it may bedetermined that the last of the plurality of outcomes has beengenerated. In another example (e.g., one in which step 115 is beingperformed by a GD), determining whether the last of the plurality ofoutcomes has been generated may comprise determining whether the sessionhas been completed by determining whether the end event defined by aparameter of the session has occurred (e.g., determining an elapsed timesince a beginning of the session).

In some embodiments an indication of a plurality of outcomes may not bereceived by a particular device performing step 115 unless and until thelast of a plurality of outcomes has been generated. In such embodiments,step 115 may be superfluous. Alternatively, an affirmative determinationto step 115 may be determined if it is determined that the indication ofthe outcomes has been received.

In one embodiment, step 115 may further comprise determining whether thelast of representative outcomes corresponding to actual outcomes of asession have been determined. For example, if step 115 is beingperformed by a device creating a video representation of the outcomes orselecting media files for the plurality of outcomes, each media filecomprising a representative outcome, step 115 may comprise determiningwhether the last of the representative outcomes has been determined(e.g., whether a representative outcome for each of a plurality ofactual outcomes comprising a session has been determined).

If it is determined that the last of the plurality of outcomes has notbeen generated (e.g., the session comprising the plurality of outcomesis not yet complete), the process returns to step 105, in which theremainder of the plurality of outcomes (or more of the plurality ofoutcomes) are determined. Otherwise, the process 100 continues to step120.

In step 120, the plurality of outcomes is sold to a purchaser inexchange for a price. Of course, it should be understood that in someembodiments the plurality of outcomes may be provided to a player orother recipient without receiving a price therefore. For example, theplurality of outcomes may be provided as a reward (e.g., for loyalty toa casino or certain desirable play behavior), gift or incentive.Further, it should be understood that any price received in exchange forthe plurality of outcomes may be a monetary amount (e.g., U.S. dollars)or may be in another form of consideration. For example, a recipient mayagree to perform an activity or engage in a behavior in exchange for theplurality of outcomes. For example, a recipient may answer survey ormarketing questions and/or commit to returning to a casino within apredetermined time frame.

Selling the plurality of outcomes to a purchaser in exchange for a pricemay comprise, for example, selling a DVD to a player, the DVD havingrecorded thereon a video representation of the plurality of outcomes.Additional detail on such an embodiment is provided below. In anotherexample, selling the plurality of outcomes to a player may compriseproviding access to the player to the plurality of outcomes in anothermanner. For example, a code may be provided to the player, the codebeing associated with an indication (e.g., a video presentation) of theplurality of outcomes as it is stored on a server device (e.g., a serverdevice operable to facilitate a Web site). The player may enter the code(e.g., online) and thus gain access to the indication of the outcomes.Additional detail on such an embodiment is provided below.

In some embodiments, selling the plurality of outcomes to a player maycomprise providing an indication of the plurality of outcomes to aplayer who has previously ordered or requested that the plurality ofoutcomes be generated, and may have already paid for the outcomes. Insuch embodiments, selling the plurality of outcomes to the player maycomprise communicating (e.g., transmitting) an indication of theoutcomes (or an indication of an availability of the outcomes) to theplayer. For example, a DVD may be mailed to the player or a code orother information (e.g., an executable file that displays representativeoutcomes when opened or run) may be e-mailed to the player.

In one embodiment, selling the plurality of outcomes to a player mayoccur at a POS of a casino. For example, a player may request topurchase a DVD of outcomes at the POS. The sale of the DVD may involvevarious procedures for ensuring the security and legitimate sale of theDVD. Such procedures are described in detail herein.

As described, in one embodiment selling a plurality of outcomes to aplayer may comprise providing the player access to a video presentationrepresenting the outcomes, such that the player may view game resultsfrom a location that is remote from a casino (though the resultsthemselves may have been generated within a casino). In someembodiments, player contact information received when a player purchasesa session or video presentation based on the session (e.g., address,phone number, e-mail address) may be used in providing the player accessto the video presentation.

In some embodiments, providing the player access to a video presentationmay comprise storing or transmitting the video presentationelectronically such that it may be accessed or viewed by the player. Forexample, in one embodiment, providing (and, e.g., creating) a videopresentation may comprise storing various media files on a server thatmay be accessible by purchasers via computing devices such as personalhome computers (of course, other computing devices, such as PDAs,cellular phones, and so on are contemplated). Accordingly, providingaccess to a video presentation may comprise allowing a player to accesssuch stored files. For example, in one embodiment, a player may beprovided with a code that may be entered (e.g., using a form of a Webpage) to gain access to such a video presentation. Such a code maycomprise a session identifier. For example, after being given a code,the player may visit a Web page and enter the code. If the code is valid(e.g., as determined by a server, the session has been executed and thecode has been legitimately provided to the player and is associated withthe session), the player may then use a Web interface (e.g., a virtualslot machine created using Macromedia Flash or a similar program) toview the stored video presentation associated with the purchasedsession. For example, the player may press a “spin” button of such avirtual slot machine, and upon doing so, a server may be operable to (i)determine a game play number (e.g., if it is the first time the playerhas pressed the spin button, the game play number is “1,” and so on),(ii) access a database or other memory structure based on the sessionidentifier so as to determine one or more media files in associationwith the game play number, and (iii) output the appropriate media filesvia the Web interface.

In other embodiments, as already described, a video presentation may betransmitted electronically to a player, such as via electronic mail(e.g., an executable software application is mailed electronically toplayers such that they may open the application and view outcomescomprising a purchased session) or video broadcasting.

In some embodiments, as also described, a video presentation of aplurality of outcomes comprising a session may be output via tangiblemedia such as a DVD or CD-ROM. Accordingly, in some embodiments, suchtangible media may be provided, shipped or mailed to a purchaser of asession. For example, the tangible media may be handed to the playerupon the player purchasing the session, may be mailed to a mailingaddress indicated by a player, may be stored in a centrally-accessibledatabase or in written form, etc.

It should be understood that the various steps of process 100 may occurat different locations. For example, a plurality of outcomes may begenerated at a casino and transmitted to a DVD assembly facility that isremote from the casino. The DVD assembly facility may then create a DVDhaving recorded therein a video representation of the plurality ofoutcomes. Various processes for how such a DVD may be created aredescribed in detail herein. The DVDs assembled at such a DVD assemblyfacility may then be transported to another location (e.g., to a casino,to be made available for sale to players or directly to a player's homeif the player has previously ordered a DVD). FIG. 2, described below,illustrates the various processes and locations that may be involved insome embodiments of the present invention.

Referring now to FIG. 2, illustrated therein is a block diagram of anexample “life cycle” of a DVD according to some embodiments describedherein. The block diagram illustrates the various entities and processesthat may be involved in at least one embodiment described herein. Itshould be noted that each of the processes described briefly withrespect to FIG. 2 is described in detail herein. FIG. 2 is providedherein to illustrate one possible implementation of some embodiments.

As illustrated in FIG. 2, in accordance with some embodiments threedistinct locations may be involved in providing a DVD of outcomes to aplayer. The first location is a casino 205, at which a player maypurchase and redeem a DVD. The second location is a DVD creationfacility 210, at which a DVD of outcomes may be created based onoutcomes determined by a GD. The third location is a player's home 215or other location remote from a casino, at which location one or moreplayers may view a DVD of outcomes.

The casino 205 may include a CS 225 that facilitates the sale andredemption of DVDs of outcomes. The CS 225 is in communication with a GD220 at which outcomes are created, based on which outcomes a videopresentation of outcomes for the DVD will be created. The CS 225 is alsoin communication with a POS 230, at which a player may purchase a DVD ofoutcomes.

The DVD creation facility includes a DVD assembly system 235 (DVD AS235). The DVD AS 235 is comprised of a computer 240 and a DVD recordingdevice 245.

The player home 215 may include a TV 250 in communication with a DVDplayer 255. It should be understood, of course, that if a tangiblemedium other than a DVD is used to provide a video presentation ofoutcomes to a player, the player home 215 may include devicesappropriate for reading and outputting the video presentation to aplayer (e.g., if the outcomes are stored on a CD-ROM, the player homemay include a PC operable to read and output the information recorded onthe CD-ROM).

A player's obtainment of a DVD of outcomes may begin with a processP-200-1, in which GD 220 generates a plurality of outcomes for a sessionand communicates (e.g., transmits) an indication of the plurality ofoutcomes to CS 225. In an alternate embodiment, GD 220 may communicatean indication of the plurality of outcomes directly to DVD AS 235 (e.g.,in lieu of or in addition to communicating the indication to CS 225). Itshould be noted that, as described, a player (or players) may haverequested the plurality of outcomes or session prior to the outcomesbeing generated. In such embodiments, a player's obtainment of a DVD ofoutcomes may instead begin with a process in which a player approaches aPOS 230 to request the plurality of outcomes (and, e.g., provides thedesired parameters and values thereof for the session comprising theplurality of outcomes). However, for purposes of simplicity, FIG. 2illustrates an embodiment in which DVDs are mass produced, without thecreation of a DVD being dependent on a player requesting a purchase of aparticular session.

Once the GD 220 (or another device since, as described herein, anyreference to a particular device performing a particular function is notmeant to be limiting since the function may be performed by anotherdevice, as desired and practicable) transmits an indication of theplurality of outcomes, which may be referred to as session result data,the CS 225 communicates the session result data to DVD AS 235 in aprocess P-200-2. For example, the CS 225 may electronically communicatethe session result data in an encrypted fashion to DVD AS 235. Thesession result data may include, for example, an indication of one ormore of (i) a game for which the plurality of outcomes were generated;(ii) a price of the session; (iii) a beginning credit meter balance forthe session; (iv) an ending credit meter balance for the session; (iv) anumber of game plays included in the session; (v) a wager per game play;(vi) a sum of payouts obtained for the session; (vi) particular outcomes(e.g., sets of indicia and/or payouts) obtained during the session;(vii) a strategy employed during the session (e.g., if anydecision-making is required during a game play); (viii) a sessionidentifier, and/or (ix) a number of players associated with the session.

The computer 240 may then create a video presentation based on thereceived session result data. For example, the computer 240 may selector create appropriate media files (e.g., video clips, each video clipcorresponding to a particular representative outcome to be included inthe video presentation) based on the received session result data. Thecomputer 240 may also determine an order in which the media files are tobe put together in the video presentation. Such an order may bedetermined, for example, based on an order in which outcomes weregenerated by GD 220 (which order may be included in the session resultdata received). In another example, the order may be determined based onanother desired characteristic. For example, it may be desirable torepresent the outcomes such that the majority of outcomes correspondingto large payouts occur towards the end of the video presentation or suchthat payouts that correspond to payouts greater than zero aresubstantially evenly interspersed among outcomes that correspond topayouts of zero credits. It should be understood that a videopresentation created in accordance with some embodiments may includedata other than the mere representation of outcomes obtained as a resultof a session. For example, inserted pauses to mimic a time at which aplayer would normally pull a slot machine handle or otherwise initiatethe next game play may be interspersed between each video cliprepresenting an outcome, to approximate the experience a player may havewhile playing a GD on a casino floor. This additional data may be, insome embodiments, additional video data, or in other embodiments,navigation data such as DVD pause commands. In another example, audioand/or video of messages may also be included (e.g., congratulatorymessages appear upon an outcome corresponding to a large payout beingdisplayed).

According to some embodiments discussed further herein, a videopresentation may be based on the number of players associated with thesession. For example, a video presentation may be organized to displayresults for each of a plurality of simulated players simultaneously, insuccession, alternately, etc.

Once the computer 240 creates a video presentation (e.g., selects themedia files to be included in the video presentation and the orderthereof), the computer 240 may, in process P-200-3, direct the DVDrecording device to record the video presentation onto a DVD. The DVDrecording device records (e.g., stamps) the video presentation onto aDVD.

Once the DVD is created (which, in some embodiments, may include storingthe DVD in a jewel case, including marketing materials with the DVD,labeling the DVD with unique identifiers (e.g., in the form of barcodes)as appropriate, and wrapping the DVD in secure packaging), the DVD istransported from the DVD creation facility 210 to the casino 205 inprocess P-200-4. For example, a shipment of DVDs created in accordancewith the above processes may be shipped to the casino. Additionally,data indicative of the DVDs created and being shipped may becommunicated to the casino 205. For example, an indication of a uniqueDVD identifier that corresponds to a unique session identifier of asession based on which the DVD was created may be communicated. Suchinformation may be communicated electronically and/or via printed form(e.g., as documents included in the shipment).

Once the DVD arrives at the casino 205, it is made available forpurchase to players. For example, the DVD may be placed on a display ofDVDs on a casino floor (e.g., next to a GD that is operable tofacilitate a game based on which the outcomes of the DVD weregenerated), behind a casino counter, in a casino hotel room, etc.Information regarding the DVD is stored in CS 225. For example, theunique DVD identifier (which may also be included on the DVD and/or DVDpackaging) may be stored in an available DVDs database 445, along withother information associated with the DVD (e.g., a redemption value ofthe DVD and a status of the DVD (e.g., whether it has yet been soldand/or redeemed)).

A player who desires to purchase the DVD may then request to purchasethe DVD at POS 230. For example, a player may select the DVD from adisplay on a casino floor and bring it to POS 230. In another example,the DVD may be available at a merchant associated with the casino andPOS 230 and the player may select the DVD from a shelf of the merchantand present it for purchase at POS 230. In yet another example, the DVDmay be located behind an employee counter of a POS 230 and the playermay request to purchase the DVD by informing a casino attendant, whoselects the DVD from behind the counter for the player. The purchase ofthe DVD is facilitated in process P-200-5, in which process the POS 230communicates with CS 225 to verify that the DVD has not previously beenpurchased and is available for sale. The process P-200-5 may includeother steps for ensuring that the DVD is sold in a secure manner, asdescribed in detail herein. For example, an identifier of the player maybe received and/or an activation code for the DVD may be received fromCS 225. Once the player provides the appropriate price for the DVD, theplayer is provided with the receipt and DVD and the purchase iscomplete.

The player may then take the DVD home in process P-200-6 and view thevideo presentation of outcomes at his leisure (alone or with otherplayers). The player (and/or one or more other players associated withthe DVD) may subsequently return to the casino and request a payment ofa redemption value of the DVD (all or or some portion of a totalredemption value), in process P-200-7. For example, the player may visitPOS 230 in order to redeem the DVD. For example, if the ending creditmeter balance of a session, which the DVD redemption value is a functionof, is greater than zero, the player may obtain the redemption value byreturning to the casino with the DVD and receipt.

Upon receiving a request to collect a redemption value of a DVD at a POS230, a process is performed for verifying and authorizing the provisionof the redemption value to the player. For example, a legitimatepurchase by the player of the DVD may be verified. In another example,the association of the player with the DVD may be verified.Additionally, it may be verified that the redemption value has notpreviously been collected. An example redemption process for redeeming aredemption value of a DVD is described in detail herein with respect toFIG. 27.

Of course, it should be understood that a player need not view the videopresentation in order to collect the DVD redemption value. As describedherein, in some embodiments a player may be allowed to collect theredemption value of a purchased DVD without ever opening the DVD and/orviewing the video presentation of the DVD. Further, it should be notedthat, in some embodiments, a player need not return to the casino inorder to collect the DVD redemption value. As is described herein, insome embodiments the DVD redemption value may be provided to the playerwho purchased the DVD after a predetermined period of time from thepurchase of the DVD passes (e.g., one month after the DVD is purchased,a check for the redemption value is mailed to the player if the playerhas not yet collected the redemption value). In some embodiments, aplayer may request to collect the redemption value of a DVD withoutbeing required to visit the casino (e.g. a player may call or e-mail thecasino or send in his DVD and receipt therefor via postal mail in orderto collect the redemption value).

In some embodiments, as described herein, a player may be provided witha benefit for returning to a casino after purchasing a DVD even if theDVD redemption value is zero or the credit meter balance associated withthe session based on which the DVD was created was zero. For example, aplayer may be provided with free game plays, comp points, discounts, orother prizes.

2. Rules of Interpretation

Numerous embodiments are described in this disclosure, and are presentedfor illustrative purposes only. The described embodiments are notintended to be limiting in any sense. The invention is widely applicableto numerous embodiments, as is readily apparent from the disclosureherein. These embodiments are described in sufficient detail to enablethose skilled in the art to practice the invention, and it is to beunderstood that other embodiments may be utilized and that structural,logical, software, electrical and other changes may be made withoutdeparting from the scope of the present invention. Accordingly, thoseskilled in the art will recognize that the present invention may bepracticed with various modifications and alterations. Althoughparticular features of the present invention may be described withreference to one or more particular embodiments or figures that form apart of the present disclosure, and in which are shown, by way ofillustration, specific embodiments of the invention, it should beunderstood that such features are not limited to usage in the one ormore particular embodiments or figures with reference to which they aredescribed. The present disclosure is thus neither a literal descriptionof all embodiments of the invention nor a listing of features of theinvention that must be present in all embodiments.

The terms “an embodiment”, “embodiment”, “embodiments”, “theembodiment”, “the embodiments”, “an embodiment”, “some embodiments”, “anexample embodiment”, “at least one embodiment”, “one or moreembodiments” and “one embodiment” mean “one or more (but not necessarilyall) embodiments of the present invention(s)” unless expressly specifiedotherwise. The terms “including,” “comprising” and variations thereofmean “including but not limited to”, unless expressly specifiedotherwise.

The term “of” and variations thereof mean “including and limited to,”unless expressly specified otherwise.

The enumerated listing of items does not imply that any or all of theitems are mutually exclusive. The enumerated listing of items does notimply that any or all of the items are collectively exhaustive ofanything, unless expressly specified otherwise. The enumerated listingof items does not imply that the items are ordered in any manneraccording to the order in which they are enumerated.

The term “comprising at least one of” followed by a listing of itemsdoes not imply that a component or subcomponent from each item in thelist is required. Rather, it means that one or more of the items listedmay comprise the item specified. For example, if it is said “wherein Acomprises at least one of: a, b and c” it is meant that (i) A maycomprise a, (ii) A may comprise b, (iii) A may comprise c, (iv) A maycomprise a and b, (v) A may comprise a and c, (vi) A may comprise b andc, or (vii) A may comprise a, b and c.

The terms “a,” “an” and “the” mean “one or more,” unless expresslyspecified otherwise.

The term “based on” means “based at least on,” unless expresslyspecified otherwise.

The methods described herein (regardless of whether they are referred toas methods, processes, algorithms, calculations, and the like)inherently include one or more steps. Therefore, all references to a“step” or “steps” of such a method have antecedent basis in the mererecitation of the term “method” or a like term. Accordingly, anyreference in a claim to a “step” or “steps” of a method is deemed tohave sufficient antecedent basis.

Headings of sections provided in this document and the title are forconvenience only, and are not to be taken as limiting the disclosure inany way.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries.

A description of an embodiment with several components in communicationwith each other does not imply that all such components are required, orthat each of the disclosed components must communicate with every othercomponent. On the contrary a variety of optional components aredescribed to illustrate the wide variety of possible embodiments of thepresent invention.

Further, although process steps, method steps, algorithms or the likemay be described in a sequential order, such processes, methods andalgorithms may be configured to work in alternate orders. In otherwords, any sequence or order of steps that may be described in thisdocument does not, in and of itself, indicate a requirement that thesteps be performed in that order. The steps of processes describedherein may be performed in any order practical. Further, some steps maybe performed simultaneously despite being described or implied asoccurring non-simultaneously (e.g., because one step is described afterthe other step). Moreover, the illustration of a process by itsdepiction in a drawing does not imply that the illustrated process isexclusive of other variations and modifications thereto, does not implythat the illustrated process or any of its steps are necessary to theinvention, and does not imply that the illustrated process is preferred.

It will be readily apparent that the various methods and algorithmsdescribed herein may be implemented by, e.g., appropriately programmedgeneral purpose computers and computing devices. Typically a processor(e.g., a microprocessor or controller device) will receive instructionsfrom a memory or like storage device, and execute those instructions,thereby performing a process defined by those instructions. Further,programs that implement such methods and algorithms may be stored andtransmitted using a variety of known media.

When a single device or article is described herein, it will be readilyapparent that more than one device/article (whether or not theycooperate) may be used in place of a single device/article. Similarly,where more than one device or article is described herein (whether ornot they cooperate), it will be readily apparent that a singledevice/article may be used in place of the more than one device orarticle.

The functionality and/or the features of a device may be alternativelyembodied by one or more other devices which are not explicitly describedas having such functionality/features. Thus, other embodiments of thepresent invention need not include the device itself.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing data (e.g., instructions) that may beread by a computer, a processor or a like device. Such a medium may takemany forms, including but not limited to, non-volatile media, volatilemedia, and transmission media. Non-volatile media include, for example,optical or magnetic disks and other persistent memory. Volatile mediamay include dynamic random access memory (DRAM), which typicallyconstitutes the main memory. Transmission media may include coaxialcables, copper wire and fiber optics, including the wires or otherpathways that comprise a system bus coupled to the processor.Transmission media may include or convey acoustic waves, light waves andelectromagnetic emissions, such as those generated during radiofrequency (RF) and infrared (IR) data communications. Common forms ofcomputer-readable media include, for example, a floppy disk, a flexibledisk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM,DVD, any other optical medium, punch cards, paper tape, any otherphysical medium with patterns of holes, a RAM, a PROM, an EPROM, aFLASH-EEPROM, any other memory chip or cartridge, a carrier wave asdescribed hereinafter, or any other medium from which a computer canread.

Various forms of computer readable media may be involved in carryingsequences of instructions to a processor. For example, sequences ofinstruction (i) may be delivered from RAM to a processor, (ii) may becarried over a wireless transmission medium, and/or (iii) may beformatted according to numerous formats, standards or protocols, such asTransmission Control Protocol, Internet Protocol (TCP/IP), Wi-Fi,Bluetooth, TDMA, CDMA, and 3G.

Where databases are described, it will be understood by one of ordinaryskill in the art that (i) alternative database structures to thosedescribed may be readily employed, and (ii) other memory structuresbesides databases may be readily employed. Any schematic illustrationsand accompanying descriptions of any sample databases presented hereinare illustrative arrangements for stored representations of information.Any number of other arrangements may be employed besides those suggestedby the tables shown. Similarly, any illustrated entries of the databasesrepresent exemplary information only; those skilled in the art willunderstand that the number and content of the entries can be differentfrom those illustrated herein. Further, despite any depiction of thedatabases as tables, other formats (including relational databases,object-based models and/or distributed databases) could be used to storeand manipulate the data types described herein. Likewise, object methodsor behaviors of a database can be used to implement the processes of thepresent invention. In addition, the databases may, in a known manner, bestored locally or remotely from a device that accesses data in such adatabase.

For example, as an example alternative to a database structure forstoring information, a hierarchical electronic file folder structure maybe used. A program may then be used to access the appropriateinformation in an appropriate file folder in the hierarchy based on afile path named in the program.

It should also be understood that, to the extent that any term recitedin the claims is referred to elsewhere in this document in a mannerconsistent with a single meaning, that is done for the sake of clarityonly, and it is not intended that any such term be so restricted, byimplication or otherwise, to that single meaning.

In a claim, a limitation of the claim which includes the phrase “meansfor” or the phrase “step for” means that 35 U.S.C. § 112, paragraph 6,applies to that limitation.

In a claim, a limitation of the claim which does not include the phrase“means for” or the phrase “step for” means that 35 U.S.C. § 112,paragraph 6 does not apply to that limitation, regardless of whetherthat limitation recites a function without recitation of structure,material or acts for performing that function. For example, in a claim,the mere use of the phrase “step of” or the phrase “steps of” inreferring to one or more steps of the claim or of another claim does notmean that 35 U.S.C. § 112, paragraph 6, applies to the step(s)referenced.

With respect to a means or a step for performing a specified function inaccordance with 35 U.S.C. § 112, paragraph 6, the correspondingstructure, material or acts described in the specification, andequivalents thereof, may perform additional functions as well as thespecified function.

Computers, processors, computing devices and like products arestructures that can perform a wide variety of functions. Such productscan be operable to perform a specified function by executing one or moreprograms, such as a program stored in a memory device of that product orin a memory device which that product accesses. Unless expresslyspecified otherwise, such a program need not be based on any particularalgorithm, such as any particular algorithm that might be disclosed inthe present application. It is well known to one of ordinary skill inthe art that a specified function may be implemented via differentalgorithms, and any of a number of different algorithms would be a meredesign choice for carrying out the specified function.

Therefore, with respect to a means or a step for performing a specifiedfunction in accordance with 35 U.S.C. § 112, paragraph 6, structurecorresponding to a specified function includes any product programmed toperform the specified function. Such structure includes programmedproducts which perform the function, regardless of whether such productis programmed with (i) a disclosed algorithm for performing thefunction, (ii) an algorithm that is similar to a disclosed algorithm, or(iii) a different algorithm for performing the function.

3. Systems

Referring now to FIG. 3, illustrated therein is a block diagram of anembodiment 300 of an example system that may be utilized to implementone or more embodiments described herein. Embodiment 300 is referred toas system 300 herein. The system 300 comprises a casino server 305 (CS305). An example embodiment of CS 305 is described in detail herein withrespect to FIG. 4.

The CS 305 is operable to communicate with an assembly system 310 (AS310). The AS 310 may be operable, for example, to assemble or otherwisecreate or facilitate DVDs or other tangible media storing outcomes inaccordance with embodiments described herein. An example embodiment ofAS 310 is described herein with respect to FIG. 5. In one embodiment, AS310 may be located in a location remote from a casino in which a CS 305is located. In other embodiments, AS 310 may be located in the samelocation as CS 305. In one embodiment, some or all of the functionsdescribed herein as being performed by AS 310 may instead or in additionbe performed by CS 305 and/or another device. In some embodiments CS 305and AS 310 are operated by the same entity, irrespective of whether theyare each located in the same location or remote locations (e.g., acasino may operate both). In other embodiments, CS 305 is operated by afirst entity (e.g., a casino) while AS 310 is operated by a secondentity (e.g., a manufacturer of gaming devices).

The CS 305 is further operable to communicate with one or more gamingdevices 315 (GD 315). A GD 315 may be operable, for example, to generatea plurality of outcomes in accordance with embodiments described herein.A GD 315 may comprise, in one embodiment, a GD on a casino floor that isalso operable to be used by a player in a conventional manner. In otherembodiments, GD 315 may comprise a modified GD (MGD) that is describedin detail herein with respect to FIG. 6. Although only a single GD isshown, any number of GDs may be used. An example embodiment of a GD 315is described herein with respect to FIG. 6.

The CS 305 is further operable to communicate with a Point-of-Sale 320(POS 320). Although only a single POS is shown, any number of POSs maybe used. The CS 305 is further operable to communicate with a casinopersonnel device 325 (CPD 325). A CPD may be used, for example, by anemployee of a casino to facilitate one or more embodiments describedherein. Although only a single CPD is shown, any number may be used.

In some embodiments, various casino locations (e.g., change booths,customer service counters, kiosks, shops, restaurants, etc.) may utilizePOS terminals to facilitate various processes described herein. Forexample, in some embodiments, a player may purchase a DVD containing aplurality of outcomes previously generated by a GS 315 via a POS 320. Inanother example, a player may request at a POS 320 that a plurality ofoutcomes be generated in accordance with one or more parametersspecified by the player and stored on a DVD to be provided to theplayer. Thus, in some embodiments, a POS may be utilized to (i) receivefrom a player a request to purchase a DVD of outcomes; (ii) verifyand/or authorize the sale of the DVD; (iii) accept payment in exchangefor the DVD; and/or (iv) provide a payout corresponding to the DVD upona player's authorized redemption of the DVD. In some embodiments, a POS320 may be operable to communicate with CS 305 to authorize the saleand/or redemption of a DVD. In some embodiments, a POS 320 may beconfigured to read from and/or write to one or more databases of thepresent invention (e.g., an available DVDs database). In someembodiments, a POS 320 may comprise various hardware and softwaredescribed herein with respect to other devices (e.g., a keyboard,processor, display, etc.). In some embodiments, a POS 320 may beoperable to communicate with a device in addition to CS 305. Forexample, POS 320 may be operable to communicate with aninventory/reservation system (e.g., a computer terminal at a theatrecommunicates with an inventory database to determine a number of unsoldseats for a certain event). In some embodiments, CS 305 may function asan inventory/reservation system.

In some embodiments, various casino employees may be equipped with orotherwise utilize one or more CPDs. A CPD 325 may comprise, for example,a PDA or other computing device (e.g., a personal computer terminal). ACPD 325 may comprise various input devices (e.g., a keypad, atouch-sensitive display screen, a card reader, an infrared bar codescanner, etc.), various output devices (e.g., an LCD screen), aprocessor, a memory and/or a communications port, as described hereinwith respect to other devices. In some embodiments, a CPD 325 may beoperable to communicate with a GD 315, CS 305, another server, a kiosk,a peripheral device, AS 310 and/or an inventory/reservation system of acasino-maintained property (e.g., a hotel). Thus, a CPD 325 may beconfigurable to, among other things, (i) read from and/or write to oneor more databases of the present invention, (ii) assist in payments madeto players (e.g., a representative “scans” a receipt for a purchased DVDand determines a value associated with the receipt, and if the receiptis valid, provides payment equal to the value), (iii) assist in paymentmade by players (e.g., a casino representative may receive a paymentfrom a player for purchasing a DVD as described herein and obtain anactivation code for the DVD to provide to the player); (iv) cause a GDto generate a plurality of outcomes for storage on a DVD in accordancewith embodiments described herein; and/or (v) execute or assist in theexecution of various other processes described herein. In one or moreembodiments, a CPD may be operable to read data from and/or write datato one or more of the databases described herein. A memory of a CPD maystore a program for executing processes described herein, or portionsthereof.

The CS 305 may communicate with any and all of AS 310, GD 315, POS 320and CPD 325 directly or indirectly, via a wired or wireless medium suchas the Internet, LAN, WAN or Ethernet, Token Ring, or via anyappropriate communications means or combination of communications means.For example, in one embodiment communication among any and all of thedevices of system 300 may occur over the Internet through a Web sitemaintained by computer on a remote server or over an on-line datanetwork including commercial on-line service providers, bulletin boardsystems and the like. In yet other embodiments, communication among anyof the devices of system 300 may occur over RF, cable TV, satellitelinks and the like.

It should be noted that the lines connecting the various devices ofsystem 300 do not imply that the devices are operable to communicate viaa particular network. For example, AS 310 may not be located on anetwork that CS 305, GD 310, POS 320 and CPD 325 are located on.

Further, any and all of the CS 305, AS 310, GD 315, POS 320 and CPD 325may comprise a computing device (or one or more computing devices), suchas those based on the Intel® Pentium® processor.

In some embodiments, communication among some or all of the devices 300may occur over a network. Some, but not all, possible communicationnetworks that may comprise the system 300 include: a LAN, a WAN, theInternet, a telephone line, a cable line, a radio channel, an opticalcommunications line, and a satellite communications link. For example,GD 315 may communicate with CS 305 over a LAN while CS 305 maycommunicate with AS 310 over a WAN or via a cable line.

Possible communications protocols that may be part of the system 300include: Ethernet (or IEEE 802.3), SAP, ATP, Bluetooth™, and TCP/IP.Communication may be encrypted to ensure privacy and prevent fraud inany of a variety of ways well known in the art.

A variety of communications protocols may be part of the system 300 oranother system operable to facilitate the embodiments described herein,including but not limited to: Ethernet (or IEEE 802.3), SAP, SAS™,SuperSAS™, ATP, Bluetooth™, and TCP/IP. Further, in some embodiments,various communications protocols endorsed by the Gaming StandardsAssociation of Fremont, Calif., may be utilized, such as (i) the GamingDevice Standard (GDS), which may facilitate communication between agaming device and various component devices and/or peripheral devices(e.g., printers, bill acceptors, etc.), (ii) the Best of Breed (BOB)standard, which may facilitate communication between a gaming device andvarious servers related to play of one or more gaming devices (e.g.,servers that assist in providing accounting, player tracking, contentmanagement, ticket-in/ticket-out and progressive jackpot functionality),and/or (iii) the System-to-System (S2S) standard, which may facilitatecommunication between game-related servers and/or casino propertymanagement servers (e.g., a hotel server comprising one or moredatabases that store information about booking and reservations).Communication may be encrypted to ensure privacy and prevent fraud inany of a variety of ways well known in the art.

In some embodiments, a CS 305 may not be necessary and/or may not bepreferred. For example, one or more embodiments may be practiced on astand-alone GD 315 (e.g., one operable to output a DVD of outcomes,and/or one associated with a device operable to output a DVD ofoutcomes) and/or a GD 315 operable to communicate with AS 310 directly.In such embodiments, any functions described as performed by the CS 305or data described as stored on the CS 305 may instead be performed by orstored on one or more GD 315 and/or AS 310.

It should be understood that referring to CS 305 as a “casino” server isnot meant to imply that a casino controls, or exclusively controls, thisdevice or all functions thereof. For example, in one embodiment CS 305is a device operated by an entity other than a casino (e.g., an entitythat also operates AS 310 or controls some functions of AS 310). CS 305may be any device operable to facilitate the creation of a DVD thatstores a plurality of outcomes in accordance with embodiments describedherein.

In one embodiment, CS 305 may in turn be in communication with anotherelectronic device that is distinct from a GD 315 and/or AS 310, whichelectronic device may be operable to (i) direct the CS 305 to performcertain functions and/or (ii) read data from and/or write data to the CS305. For example, the CS 305 may comprise a slot server or DataCollection Unit (DCU) that controls and/or communicates with a bank ofslot machines, which slot server or DCU is in turn in communication witha casino server that is in communication with a plurality of such slotservers or DCUs.

In another embodiment, the CS 305 may be operable to communicate with aGD 315 via another electronic device (e.g., a DCU), such as a servercomputer operable to communicate with a plurality of slot machines. Forexample, in one embodiment, the CS 305 may be operable to communicatewith a plurality of computing devices, each computing device operable tocommunicate with a respective plurality of gaming devices.

It should be noted that, in some embodiments, one or more of the devicesdescribed with respect to system 300 may be combined (or the functionsdescribed with respect to may be combined as being performed by) asingle device. For example, CS 305 and AS 310 may comprise the samedevice or a single device may perform the functions described herein asbeing performed by the two devices as embodying two distinct devices. Inanother example, GD 315 may comprise CS 305 and/or AS 310 and may, insome embodiments, perform some or all of the functions described hereinas being performed by CS 305 and/or AS 310, and vice versa.

Referring now to FIG. 4, illustrated therein is a block diagram of anexample embodiment 400 of a CS (e.g., the CS 305 of FIG. 3). Theembodiment 400 is referred to herein as CS 400. The CS 400 may beimplemented as a system controller, a dedicated hardware circuit, anappropriately programmed general-purpose computer, or any otherequivalent electronic, mechanical or electro-mechanical device. The CS400 may comprise, for example, one or more server computers operable tocommunicate with one or more client devices, such as one or more GDs, anAS, one or more kiosks, one or more POSs, one or more peripheraldevices, and/or one or more CPDs. The CS 400 may be operative to managethe system 300 or at least to facilitate some functions or proceduresdescribed herein.

In operation, the CS 400 may function under the control of a casino,another merchant, an entity that may also control use of the GD 315,and/or a GD manufacturer. For example, the CS 400 may be a slot serverin a casino. In some embodiments, the CS 400 and a slot server may bedifferent devices. In some embodiments, the CS 400 may comprise aplurality of computers operating together. In some embodiments, the CS400 and a GD 315 may be the same device.

The CS 400 comprises a processor 405, such as one or more Intel®Pentium® processors. The processor 405 is in communication with acommunication port 410 (e.g., for communicating with one or more otherdevices, such as one or more GDs 315 and/or AS 310) and a memory 415.The memory 415 may comprise an appropriate combination of magnetic,optical and/or semiconductor memory, and may include, for example,Random Access Memory (RAM), Read-Only Memory (ROM), a compact discand/or a hard disk. The processor 405 and the memory 415 may each be,for example: (i) located entirely within a single computer or otherdevice; or (ii) connected to each other by a remote communicationmedium, such as a serial port cable, telephone line or radio frequencytransceiver. In one embodiment, the CS 400 may comprise one or moredevices that are connected to a remote server computer for maintainingdatabases.

The memory 415 stores a program 420 for controlling the processor 405.The processor 405 performs instructions of the program 420, and therebyoperates in accordance with at least some of the methods described indetail herein. The program 420 may be stored in a compressed, uncompiledand/or encrypted format. The program 420 furthermore includes programelements that may be necessary, such as an operating system, a databasemanagement system and “device drivers” for allowing the processor 405 tointerface with computer peripheral devices. Appropriate program elementsare known to those skilled in the art, and need not be described indetail herein. The program 420 may include computer program code thatallows the CS 400 to employ the communication port 410 to communicatewith a GD (e.g., GD 600, described below with respect to FIG. 6) and/oran AS (e.g., AS 500, described below with respect to FIG. 5) in orderto, for example:

-   -   1. track gambling or other activity performed at the GD;    -   2. instruct a GD to generate a plurality of outcomes in        accordance with one or more parameters;    -   3. receive an indication of a plurality of outcomes generated by        a GD;    -   4. transmit an indication of a plurality of outcomes generate by        a GD to an AS;    -   5. receive an indication of a DVD of outcomes that is available        for sale;    -   6. receive a request from a player to create a DVD of outcomes;    -   7. instruct a gaming device to perform one or more functions        (e.g., output a message to a player, interrupt play, etc.);    -   8. authorize a sale of a DVD to a player;    -   9. authorize a redemption of a DVD by a player; and/or    -   10. determine an activity status of a GD.

According to some embodiments, CS 400 may be operable to perform some ofthe processes (or portions thereof) described herein. For example, CS400 may be operable to perform at least a portion of (i) process 100(described with respect to FIG. 1, above), (ii) process 1900 (describedwith respect to FIG. 19, below); (iii) process 2200 (described withrespect to FIG. 22, below); (iv) process 2600 (described with respect toFIG. 26, below); and/or any other process described herein.

According to an embodiment, the instructions of the program 420 may beread into a main memory from another computer-readable medium, such asfrom a ROM to RAM. Execution of sequences of the instructions in program420 causes processor 405 to perform the process steps described herein.In alternate embodiments, hard-wired circuitry may be used in place of,or in combination with, software instructions for implementation of theprocesses of the present invention. Thus, embodiments of the presentinvention are not limited to any specific combination of hardware andsoftware.

The memory 415 also stores (i) a session database 425; (ii) a gamingdevice database 430; (iii) an active sessions database 435; and (iv) anavailable DVDs database 440. Each of the databases 425 through 440 isdescribed in more detail below (with reference to FIGS. 7-10,respectively).

In some embodiments (e.g., in an embodiment in which CS 400 managesdownloadable games playable on one or more GDs), the memory 415 maystore additional databases. Examples of such additional databasesinclude, but are not limited to, (i) a game database that storesinformation regarding one or more games playable on and/or downloadableto one or more GDs, and (ii) a scheduling and/or configuration databaseuseful for determining which games are to be made available on which GDsat what times. In other embodiments, some or all of these functions maybe handled by a device distinct from CS 400.

Similarly, in one embodiment CS 400 may be operable to configure a GD(and/or another device, such as a kiosk, POS, CDP, etc.) remotely,update software stored on a GD and/or to download software or softwarecomponents to a GD. For example, CS 400 may be operable to apply a hotfix to software stored on a GD, modify a payout and/or probability tablestored on a GD and/or transmit a new version of software and/or asoftware component to a GD. The CS 400 may be programmed to perform anyor all of the above functions based on, for example, an occurrence of anevent (e.g., a scheduled event), receiving an indication from aqualified casino employee and/or other person (e.g., a regulator) and/orreceiving a request from a player. In other embodiments, some or all ofthese functions may be handled by a device distinct from CS 400.

Although the databases 425 through 440 are described as being stored ina memory of CS 400, in other embodiments some or all of these databasesmay be partially or wholly stored, in lieu of or in addition to beingstored in a memory of CS 400, in a memory of one or more other devices.Such one or more other devices may comprise, for example, one or moreperipheral devices, one or more GDs, an AS, a slot server (if differentfrom the CS 400), another device, or a combination thereof. Further,some or all of the data described as being stored in the memory 415 maybe partially or wholly stored (in addition to or in lieu of being storedin the memory 415) in a memory of one or more other devices. Such one ormore other devices may comprise, for example, one or more peripheraldevices, one or more GDs, an AS, a slot server (if different from CS400), another device, or a combination thereof.

The processor 405 is also operable to communicate with one or more inputdevices 445. An input device may comprise any device operable tofacilitate input to the CS 400 (e.g., input by a person, such as akeyboard or mouse). An input device, as the term is used herein, may beany device, element or component (or combination thereof) that iscapable of receiving an input (e.g., from a player or another device).An input device may communicate with or be part of another device (e.g.,an AS, a GD, etc.). Some examples of input devices include: a bar-codescanner, a magnetic stripe reader, a computer keyboard or keypad, abutton (e.g., mechanical, electromechanical or “soft”, as in a portionof a touch-screen), a handle, a keypad, a touch-screen, a microphone, aninfrared sensor, a voice recognition module, a coin or bill acceptor, asonic ranger, a computer port, a video camera, a motion detector, adigital camera, a network card, a universal serial bus (USB) port, a GPSreceiver, a radio frequency identification (RFID) receiver, an RFreceiver, a thermometer, a pressure sensor, an infrared port, and aweight scale. For example, in one embodiment an authorized person mayuse an input device 450 to program or re-program CS 400 to perform afunction and/or to write data to one of the databases stored in memory415.

The processor 405 is further operable to communicate with one or moreoutput devices 450. An output device may comprise any device operable tooutput information from the CS 400. An output device, as the term isused herein, may be any device, element or component (or combinationthereof) that is capable of outputting an output (e.g., to a person oranother device). Examples of an output device include, but are notlimited to, a display (e.g., in the form of a touch screen), an audiospeaker, an infra-red transmitter, a radio transmitter, an electricmotor, a printer, a coupon or product dispenser, an infra-red port, aBraille computer monitor, and a coin or bill dispenser.

In some embodiments, CS 400 may comprise components capable offacilitating both input and output functions (i.e., input/outputdevices). In one example, a touch-sensitive display screen comprises aninput/output device (e.g., the device outputs graphics and receivesselections from an authorized person).

Referring now to FIG. 5, illustrated therein is a block diagram of anexample embodiment 500 of an AS (e.g., AS 310). Embodiment 500 isreferred to as AS 500 herein. The AS 500 may be implemented as a systemcontroller, a dedicated hardware circuit, an appropriately programmedgeneral-purpose computer, or any other equivalent electronic, mechanicalor electromechanical device. The AS 500 may comprise, for example, oneor more computer and one or more DVD recording devices operatingtogether. The AS 500 may be an example of AS 235 (FIG. 2) and/or AS 310(FIG. 3).

The AS 500 may be operable, for example, to receive session result data(e.g., an indication of a plurality of outcomes generated for a session)and to create a video representation based on this data. It should beunderstood that a video presentation may include both video and audioelements. The AS 500 may further be operable to cause a DVD recordingdevice to record (e.g., stamp) the video presentation onto a DVD. Ofcourse, if the video presentation is being stored on a tangible mediumother than a DVD (e.g., a CD-ROM), the AS may be operable to cause arecording device to record the video presentation on the appropriatetangible medium (e.g., to cause a CD-ROM recording device to record thevideo presentation onto a CD-ROM). In some embodiments, as described, anindication of outcomes may be made available to a player from a serverdevice on which the indication is stored. For example, a videopresentation of outcomes may be streamed to a player via a computer incommunication with the server. In such embodiments, AS 500 may beoperable to facilitate the output of the video presentation in anappropriate manner.

The AS 500 comprises a processor 505. The processor 505 is incommunication with a communication port 510 and a memory 515. The memory515 may comprise an appropriate combination of magnetic, optical and/orsemiconductor memory, and may include, for example, Random Access Memory(RAM), Read-Only Memory (ROM), a compact disc and/or a hard disk. Thememory 515 may comprise or include any type of computer-readable medium.The processor 505 and the memory 515 may each be, for example: (i)located entirely within a single computer or other device; or (ii)connected to each other by a remote communication medium, such as aserial port cable, telephone line or radio frequency transceiver. In oneembodiment, AS 500 may comprise one or more devices that are connectedto a remote server computer for maintaining databases.

The memory 515 stores a program 520 for controlling the processor 505.The processor 505 performs instructions of the program 520, and therebyoperates in accordance with at least some embodiments, and particularlyin accordance with the methods described in detail herein.

The program 520 may include computer program code that allows the AS 500to employ the communication port 510 to communicate with another device(e.g., CS 305) in order to, for example:

(i) receive an indication of a plurality of outcomes generated by a GD(e.g., receive session result data for one or more sessions);

(ii) communicate information about a DVD that has been created by the AS500; and/or

(iii) receive information regarding the creation of a video presentation(e.g., receive media files, instructions regarding how media files areto be assembled into a video presentation, etc.).

The memory 515 may also store one or more databases. For example, memory515 stores (i) a media file database 525; (ii) a session media filedatabase 530; (iii) a DVD production queue database 535; and (iv) anoutcome sets database 540. Of course, other databases may be stored inmemory 515.

In one or more embodiments, as described, data may be stored in a memoryof another device (e.g., a database of CS 305 or a database of anotherdevice). In one or more embodiments, AS 500 may be operable to accessthe data thereof or have information associated with the data storedtherein downloaded or otherwise made available to AS 500 as necessaryand/or appropriate. For example, AS 500 may access a memory of anotherdevice to determine one or more parameters for generating a plurality ofoutcomes in accordance with one or more embodiments (e.g., how manyoutcomes were generated for a particular session). In some embodiments,AS 500 may be operable to write data to a memory of another device.

Note that, although the databases 525, 530, 535 and 540 are described asbeing stored in AS 500, in other embodiments some or all of thesedatabases and/or data thereof may be partially or wholly stored (inaddition to or in lieu of being stored in the memory 515) in anotherdevice. Such other device may comprise, for example, CS 305, a POS 320,a CPD 325, another device and/or a combination thereof.

As described, the processor 505 is operable to communicate with acommunication port 510. The communication port 510 may be utilized, forexample, to transmit information to (or receive information from)another device, such as CS 305, a GD 315, a CPD 325, a POS 320, anotherdevice, or a combination thereof.

The processor 505 is also operable to communicate with one or more inputdevices, output devices and/or input/output devices 550. The inputdevice(s) of AS 500 may comprise any or all of the input devicesdescribed herein. Similarly, the output device(s) and/or input/outputdevice(s) of AS 500 may include any and all of such devices describedherein.

The processor 505 is further operable to communicate with one or morerecording devices 555. A recording device 555 may comprise any deviceoperable to (i) record a video presentation onto a DVD or onto anothertangible medium, (ii) transfer data or information to a DVD or othertangible medium, and/or (iii) facilitate disc image transfer, asappropriate and practicable. For example, if a video presentation isstamped onto a DVD, the recording device 555 may comprise a DVD stampingdevice. In another embodiment, DVD-R or DVD+R burners may use relativelyhigh-powered lasers to darken inks inside a recordable DVD media tosimulate the pits of traditional mass-produced DVDs. Examples of suchtechnologies are readily available, such as DVD recorders from Plextor™or Panasonic™. In some of these embodiments, the DVD recording devicemay have multiple recording devices and a robotic mechanism for discmovement into and out of the drives. Examples of this technology includeRimage's Protoge Plus™, or Microtech's™ product lines. In oneembodiment, AS 500 may comprise a computer device in communication witha barcode scanning device (i.e., input device), such as the PowerScan®SR/HD made by PSC Products™ of Eugene, Oreg.

An operator of AS 500 may access session result data by scanning abarcode of a video ticket (such as one depicted in FIG. 29, describedbelow). Such a barcode may encode, for example, a session identifier, anindication of a plurality of outcomes generated for the sessionidentified by the session identifiers (e.g., a series of outcomeidentifiers) and one or more associated GD identifiers).

As described, AS 500 may store one or more programs for creating a videopresentation to be recorded onto a DVD, based on the received sessionresult data. In some embodiments, AS 500 may be operable to receivesession result data associated with a session without communicating viaan electronic network with a casino. Rather, AS 500 may be operable toreceive session result data via barcoded tickets, other printeddocuments or via other tangible media having session result data storedthereon.

In some embodiments, AS 500 may be part of the same electronic networkas CS 305, a GD 315, a CPD 325, and a POS 320, or be otherwise operableto communicate electronically with one or more of these devices andreceive session result data in electronic form from one or more of thesedevices.

In some embodiments, AS 500 may access session result data by accessinga database storing the session result data (e.g., a session database425). For example, in some embodiments, AS 500 may access a sessiondatabase maintained on CS 305 to determine if there are any executedsessions for which DVDs have not yet been created (e.g., a record of asession database may indicate whether or not a DVD has yet been createdfor a particular session). In another embodiment, a device (e.g., CS305, CPD 325 and/or a GD 315) may send a signal transmitting sessionresult data and/or transmitting an indication that session result datashould be accessed or is available. Accordingly, AS 500 may then accessor receive the session result data.

In one embodiment, AS 500 may access session result data by accessing asmart card or other tangible medium (e.g., memory stick, flash memory,floppy disc, printed ticket, CD-ROM, DVD, etc.) with session result datastored thereon. For example, AS 500 may comprise a card reader device,such that when a card bearing session result data is inserted, sessionresult data may be accessed. Such data may then be used to create avideo presentation recorded onto a DVD or otherwise provided to aplayer.

In one example of how a video presentation may be provided to a player,AS 500 may store and/or transmit media files electronically, such thatthey may be accessed or viewed by a purchaser of a session (e.g., usinga home computer or other user device). For example, AS 500 may create anentry in a database (which may be maintained by any of the devicesdescribed herein), the entry being associated with a session identifier.One or more game play numbers and media files may be associated with thesession identifier and an indication of these may be stored in therecord. Such a database may be accessed when a purchaser of a sessionrequests to view the video presentation associated with the session(e.g., a player accesses a Web page, and the appropriate entry of thedatabase is accessed to determine an order in which to present mediafiles). In some of these embodiments, the video may be createdsimultaneously to the viewing of the video presentation.

In another example, as described in detail herein, AS 500 may beoperable to create a DVD or CD-ROM using the media files. Accordingly,in one embodiment, a software program stored in the memory of AS 500 maybe operable to (i) determine an order in which media files are to bepresented, and (ii) instruct a recording device (e.g., a DVD recordingdevice) to transfer the information of the media files to an appropriatetangible media (e.g., a DVD) such that they may be viewable in theappropriate order. In some embodiments, such a software program mayoperate to output such video presentations substantially automatically(e.g., without requiring input from an operator or with minimum inputfrom an operator). For example, AS 500 may be operable to (i) receive orotherwise access session result data, (ii) determine media filesassociated with the data, and (iii) output video presentations based onthe media files to a tangible medium. In other embodiments, an operatormay provide input instructing AS 500 to perform various tasks (e.g., anoperator selects media files, scans barcodes, etc.). In either case, insome embodiments, a video presentation may be output via tangible media.

In embodiments wherein a tangible medium comprises a DVD, such a discmay be formatted according to a DVD encoding process as is known in theart. For example, one or more media files may be segmented into“chapters” that are individually accessible by players. For example, aDVD having recorded thereon a video presentation of a 1,000-game playsession may be segregated into 20 chapters of 50 game plays each that aplayer may watch. In one example, game plays may be segregated based onwhich player (e.g., of a plurality of players associated with the DVD)is associated with them. In another example, each media file (i.e., gameplay) may be encoded as its own chapter, such that a player may use an“enter” button of a DVD player remote control much like a “spin” buttonof a slot machine, launching each video presentation or segment of avideo presentation much like actuating a game play of a slot machine. Itshould be noted that one advantage of such a DVD format of creating avideo presentation is that many of the convenient navigation featuresassociated with watching video using a DVD player may be utilized. Forexample, a player may stop, pause, fast-forward or rewind the videopresentation, or skip chapters entirely.

In embodiments wherein physical media comprises a CD-ROM, a videopresentation may be incorporated into a software program that isexecutable by a purchaser of a session using a computing device. Thus,in some embodiments, creating a video presentation may comprise creatingan executable software application. For example, creating a videopresentation may comprise creating a software program that letspurchasers of sessions interact with the video presentation in a similarmanner to a software application of an online casino using a homecomputer. For example, a purchaser of a session may insert a CD-ROM intoan appropriate drive of a home computer, and then click on a graphic ofa “spin” button when he desires to view another outcome (e.g., thesoftware program written to the CD-ROM is operable to receive userinput, and based on the input, access and display a stored media file asis known in the art). Various software applications that may at leastassist in the creation of such DVD and CD-ROM discs may be availablecommercially. In some embodiments, the user receives data thatrepresents the outcome and a software program, which may or may not bedelivered on the same media as the outcomes, and which animate a videopresentation.

It should be noted that, in some embodiments, the order in which mediafiles are written to tangible media and/or stored electronically in adatabase or other memory structure may be immaterial (e.g., such that aplayer later viewing outcomes remotely may not necessarily watch them inthe order in which they were generated). For example, media files of avideo presentation may appear in a random order.

Referring now to FIG. 6, illustrated therein is a block diagram of anexample embodiment 600 of a GD (e.g., GD 315). Embodiment 600 isreferred to herein as GD 600. The GD 600 may be implemented as a systemcontroller, a dedicated hardware circuit, an appropriately programmedgeneral-purpose computer, or any other equivalent electronic, mechanicalor electromechanical device. The GD 600 may comprise, for example, aslot machine, a video poker terminal, a video blackjack terminal, avideo keno terminal, a video lottery terminal, a pachinko machine or atable-top game. In some embodiments, the term “slot machine” is used torefer to a GD and is meant to encompass any and all of the exampledevices listed herein. In various embodiments, a GD may comprise, forexample, a personal computer (e.g., which communicates with an onlinecasino Web site), a telephone (e.g., to communicate with an automatedsports book that provides gaming services), or a portable handheldgaming device (e.g., a personal digital assistant, Nintendo™ GameBoy™device, Sony™ PSP™ device, or other appropriate device). In someembodiments, the GD 600 may comprise a device operable to facilitate atable game (e.g., a device operable to monitor a blackjack game, such assize of a player's wager, cards received and/or decisions made). In someembodiments, a user device such as a PDA or cell phone may be used inplace of, or in addition to, some or all of the GD 600 componentsdepicted in FIG. 6.

Further, a GD 600 may comprise a personal computer or other deviceoperable to communicate with an online casino and facilitate game playat the online casino. In one or more embodiments, the GD 600 maycomprise a computing device operable to execute software that simulatesplay of a reeled slot machine game, video poker game, video blackjackgame, video keno game, video roulette game, or lottery game.

The example GD 600 comprises a processor 605, such as one or more Intel®Pentium® processors. The processor 605 is in communication with a memory610. The memory 610 may comprise an appropriate combination of magnetic,optical and/or semiconductor memory, and may include, for example,Random Access Memory (RAM), Read-Only Memory (ROM), a compact discand/or a hard disk. The memory 610 may comprise or include any type ofcomputer-readable medium. The processor 605 and the memory 610 may eachbe, for example: (i) located entirely within a single computer or otherdevice; or (ii) connected to each other by a remote communicationmedium, such as a serial port cable, telephone line or radio frequencytransceiver. In one embodiment, GD 600 may comprise one or more devicesthat are connected to a remote server computer for maintainingdatabases.

The memory 610 stores a program 615 for controlling the processor 605.The processor 605 performs instructions of the program 615, and therebyoperates in accordance with embodiments of the present invention, andparticularly in accordance with the methods described in detail herein.The program 615, as well as any other program for controlling aprocessor described herein, may be stored in a compressed, uncompiledand/or encrypted format. The following description of program 615applies equally to all programs for directing a processor describedherein. The program 615 includes program elements that may be necessary,such as an operating system, a database management system and “devicedrivers” for allowing the processor 605 to interface with computerperipheral devices. Appropriate program elements are known to thoseskilled in the art, and need not be described in detail herein.

According to an embodiment, the instructions of the program 615 may beread into a main memory from another computer-readable medium, such froma ROM to RAM. Execution of sequences of the instructions in program 615may cause processor 605 to perform one or more process steps describedherein. In alternate embodiments, hard-wired circuitry may be used inplace of, or in combination with, software instructions forimplementation of the processes of the present invention. Thus,embodiments described herein are not limited to any specific combinationof hardware and software. In some embodiments, the execution ofsequences of the instructions in a program of a peripheral deviceassociated with GD 600 may cause processor 605 to perform some or all ofthe process steps described herein.

The memory 610 may also store one or more databases. For example, memory610 may store one or more of a probability database, such as probabilitydatabase 620, and one or more of a payout database, such as payoutdatabase 625.

In one or more embodiments, as described, data may be stored in a memoryof another device (e.g., a database of CS 305 or a database of anotherdevice). In one or more embodiments, GD 600 may be operable to accessthe data thereof or have information associated with the data storedtherein downloaded or otherwise made available to GD 600 as necessaryand/or appropriate. For example, GD 600 may access a memory of anotherdevice to determine one or more parameters for generating a plurality ofoutcomes in accordance with one or more embodiments (e.g., how manyoutcomes are to be generated for a particular session). In someembodiments, GD 600 may be operable to write data to a memory of anotherdevice.

Note that, although the databases 620 and 625 are described as beingstored in GD 600, in other embodiments some or all of these databasesand/or data thereof may be partially or wholly stored (in addition to orin lieu of being stored in the memory 610) in another device. Such otherdevice may comprise, for example, CS 305, a POS 320, a CPD 325, anotherdevice and/or a combination thereof.

The processor 605 is operable to communicate with a communication port630. The communication port 630 may be utilized, for example, totransmit information to (or receive information from) another device,such as CS 305, another GD, a CPD 325, a POS 320, AS 310, anotherdevice, or a combination thereof.

The processor 605 is also operable to communicate with a random numbergenerator 635 (RNG 635), which may be a component of GD 600. The RNG 635(as well as any other random number generator described herein), inaccordance with at least one embodiment, may generate data representingrandom or pseudo-random values (referred to as “random numbers” herein).The RNG 635 may generate a random number every predetermined unit oftime (e.g., every second) or in response to an initiation of a game onthe gaming device. In the former embodiment, the generated randomnumbers may be used as they are generated (e.g., the random numbergenerated at substantially the time of game initiation is used for thatgame) and/or stored for future use.

A RNG, as used herein, may be embodied as a processor separate from butworking in cooperation with processor 605. Alternatively, a RNG may beembodied as an algorithm, program component, or software stored in thememory of a GD or other device and used to generate a random number.

Note that, although the generation or obtainment of a random number isdescribed herein as involving a RNG of a GD, other methods ofdetermining a random number may be employed. For example, a GD owner oroperator may obtain sets of random numbers that have been generated byanother entity. HotBits™, for example, is a service that provides randomnumbers that have been generated by timing successive pairs ofradioactive decays detected by a Geiger-Muller tube interfaced to acomputer. A blower mechanism that uses physical balls with numbersthereon may be used to determine a random number by randomly selectingone of the balls and determining the number thereof.

The processor 605 is also operable to communicate with a benefit outputdevice 640, which may be a component of GD 600. The benefit outputdevice 640 may comprise one or more devices for outputting a benefit toa player of GD 600. For example, in one embodiment, GD 600 may providecoins and/or tokens as a benefit. In such an embodiment the benefitoutput device 640 may comprise a hopper and hopper controller, fordispensing coins and/or tokens into a coin tray of GD 600.

In another example, GD 600 may provide a receipt or other document onwhich there is printed an indication of a benefit or other information(e.g., a cashless gaming receipt that has printed thereon a monetaryvalue, which is redeemable for cash in the amount of the monetary value,a check cashable for monetary value, etc.). In such an embodiment, thebenefit output device 640 may comprise a printing and documentdispensing mechanism. In yet another example, GD 600 may provideelectronic credits as a benefit (which, e.g., may be subsequentlyconverted to coins and/or tokens and dispensed from a hopper into a cointray). In such an embodiment, the benefit output device 640 may comprisea credit meter balance and/or a processor that manages the amount ofelectronic credits that is indicated on a display of a credit meterbalance. The processor may be the processor 605 or another processor. Inyet another example, GD 600 may credit a monetary amount to a financialaccount associated with a player as a benefit provided to a player. Thefinancial account may be, for example, a credit card account, a debitaccount, a charge account, a checking account, and/or a casino account.In such an embodiment the benefit output device 640 may comprise adevice for communicating with a server on which the financial account ismaintained.

Note that, in one or more embodiments, GD 600 may include more than onebenefit output device 640 even though only one benefit output device isillustrated in FIG. 6. For example, GD 600 may include both a hopper andhopper controller combination and a credit meter balance. Such a GD maybe operable to provide more than one type of benefit to a player of theGD. A single benefit output device 640 may be operable to output morethan one type of benefit. For example, a benefit output device 640 maybe operable to increase the balance of credits in a credit meter andcommunicate with a remote device in order to increase the balance of afinancial account associated with a player.

The processor 605 is also operable to communicate with a display device645, which may be a component of GD 600. The display device 645 maycomprise, for example, one or more display screens or areas foroutputting information related to game play on the gaming device, suchas a cathode ray tube (CRT) monitor, liquid crystal display (LCD)screen, or light emitting diode (LED) screen.

In one or more embodiments, GD 600 may comprise more than one displaydevice 645. For example, GD 600 may comprise an LCD display fordisplaying electronic reels and a display device that comprises aviewing window behind which are located mechanical reels and whichdisplays the rotation of the mechanical reels during game play. In oneembodiment, a display device 645 may be operable to display a message toa player. In one embodiment, a display device may be operable to displaya menu to a player and/or casino attendant, the menu for inputtingparameter values defining a session or plurality of outcomes to begenerated by the gaming device. An example of such a menu is describedbelow with respect to FIG. 30.

The processor 605 may also be in communication with one or more otherdevices besides the display device 645, for outputting information(e.g., to a player or another device). Such other one or more outputdevices may also be components of GD 600. Such other one or more outputdevices may comprise, for example, an audio speaker (e.g., foroutputting a message to a player, in addition to or in lieu of such amessage being output via a display device 645), an infra-redtransmitter, a radio transmitter, an electric motor, a printer (e.g.,such as for printing cashless gaming vouchers), a coupon or productdispenser, an infra-red port (e.g., for communicating with a second GDor a portable device of a player), a Braille computer monitor, and acoin or bill dispenser. For certain types of GDs, common output devicesinclude a CRT monitor on a video poker machine, a bell (e.g., that ringswhen a player wins), an LED display of a player's credit balance, and anLCD display of a PDA for displaying keno numbers.

The display device 645 may comprise, for example, one or more distinctdisplay areas and/or one or more distinct display devices. For example,one of the display areas may display outcomes of games played on the GD(e.g., electronic reels of a gaming device). Another of the displayareas may display rules for playing a game of the GD. Yet another of thedisplay areas may display the benefits obtainable by playing a game ofthe GD (e.g., in the form of a payout table). Yet another of the displayareas may display messages to the player (e.g., messages advertising theavailability of a DVD featuring outcomes of a game currently beingplayed by a player) and/or a casino attendant. For example, a messagemay indicate a summary of at least some session information regarding asession that has been executed on the GD. In one or more embodiments, GD600 may include more than one display device, one or more other outputdevices, or a combination thereof (e.g., two display devices and twoaudio speakers).

The processor 605 is also operable to communicate with an input device650, which is a device that is capable of receiving an input (e.g., froma player, casino personnel or a device) and which may be a component ofGD 600. An input device may communicate with or be part of anotherdevice (e.g. a CS 305, AS 310, POS 320, CPD 325, another GD, etc.). Someexamples of input devices include: a bar-code scanner, a magnetic stripereader, a computer keyboard or keypad, a button (e.g., mechanical,electromechanical or “soft”, as in a portion of a touch-screen), ahandle, a keypad, a touch-screen, a microphone, an infrared sensor, avoice recognition module, a coin or bill acceptor, a sonic ranger, acomputer port, a video camera, a motion detector, a digital camera, anetwork card, a USB port, a GPS receiver, a RFID receiver, an RFreceiver, a thermometer, a pressure sensor, an infrared port (e.g., forreceiving communications from with a second gaming device or a anotherdevice such as a smart card or PDA of a player), and a weight scale. Forcertain types of GDs, common input devices include a button or touchscreen on a video poker machine, a lever or handle connected to the GD,a magnetic stripe reader to read a player tracking card inserted into aGD, a touch screen for input of player selections during game play, anda coin and bill acceptor. Input device 650 may comprise any of theabove-described input devices or any combination thereof (i.e., inputdevice 650 may comprise more than one input device).

In some embodiments, a GD 600 may comprise components capable offacilitating both input and output functions (i.e., input/outputdevices). In one example, a touch-sensitive display screen comprises aninput/output device (e.g., the device outputs graphics and receivesselections from players). In another example, processor 605 maycommunicate with a “ticket-in/ticket-out” device configured to dispenseand receive cash-out tickets. Such a device may also assist in (e.g.,provide data so as to facilitate) various accounting functions (e.g.,ticket validation and redemption). For example, any or all of a GD, POS,kiosk and CPD maintained at a cashier cage may (i) comprise such abenefit input/output device, and/or (ii) communicate with a centralserver (e.g., CS 305) that manages the accounting associated with suchticket-in/ticket-out transactions (e.g., so as to track the issuance,redemption and expiration of such tickets). One example ofticket-in/ticket-out technology that may be adapted or utilized toimplement embodiments described herein is the EZ Pay™ system, ismanufactured by International Gaming Technology, headquartered in Reno,Nev.

Of course, as would be understood by one of ordinary skill in the art,GD 600 may comprise various combinations of any or all of the componentdevices described herein. For example, in one or more embodiments, thegaming device may include more than one display device, one or moreother output devices, several input devices, and so on (e.g., twodisplay screens, two audio speakers, a headset, a ticket-in/ticket-outdevice and several buttons). Further, GD 600 may include additional ordifferent components from those described herein.

The processor 605 is further operable to communicate with a paymentsystem 655, which may be a component of GD 600. The payment system 655is a device capable of accepting payment from a player (e.g., a bet orinitiation of a balance) and/or providing payment to a player (e.g., apayout). Payment is not limited to currency, but may also include othertypes of consideration, including products, services, and alternatecurrencies. Payment system 655 may be considered to be an example of aninput device 650 and/or an example of a benefit output device 640 insome embodiments.

Exemplary methods of accepting payment by the payment system 655 include(i) receiving hard currency (i.e., coins or bills), and accordingly thepayment system 655 may comprise a coin or bill acceptor; (ii) receivingan alternate currency (e.g., a paper cashless gaming voucher, a coupon,a non-negotiable token), and accordingly the payment system 655 maycomprise a bar code reader or other sensing means; (iii) receiving apayment identifier (e.g., a credit card number, a debit card number, aplayer tracking card number) and debiting the account identified by thepayment identifier; and (iv) determining that a player has performed avalue-added activity.

Processor 605 is further operable to communicate with a player trackingdevice 660, which may be a component of GD 600. Player tracking device660 may, in some embodiments, be considered an example of an inputdevice 650 and/or an example of a payment system 655 (e.g., inembodiments in which a player provides a payment by providing a playeridentifier that also functions as a monetary account identifier). Playertracking device 660 may, in one or more embodiments, comprise a readerdevice operable to read information from and/or write information to acard such as a smart card and/or a player tracking card, such that (i)players may be identified, and (ii) various data associated with playersmay then be determined. For example, previous wagering, coin-in and/orcash-out behaviors previously engaged in by the player may be determinedbased on information associated with the player identifier. In anotherexample, previous strategies employed in a video poker game may besimilarly determined. In yet another example, DVDs previously purchasedby a player may be determined (e.g., for purposes of providing a playera payment associated with the DVD). Similarly, a number of cashablecredits available to the player may be determined, a number ofpromotional credits that may not be redeemed for cash but that areassociated with the player may be determined, a code or other indicationof a benefit to be provided to the player may be determined, a number ofaccumulated loyalty points associated with the player may be determined,a number of accumulated game elements such as symbols, cards or handsassociated with the player may be determined, etc.

In one example, a card reader device comprising a player tracking device660 may determine an identifier associated with a player (e.g., byreading a player tracking card comprising an encoded version of theidentifier), such that the gaming device may then access data (e.g., ofa player database, a session database) associated with the player. Inanother example, a smart card reader device may determine dataassociated with a player directly by accessing a memory of an insertedsmart card.

Although not illustrated herein, a player database may be used, forexample, to store player wager data (e.g., such that players wageringover a given threshold in a given amount of time may be rewarded fortheir patronage, qualify for certain features, be identified as apotential problem gambler, and so on). The player database may alsocontain other information that may be useful in, for example, promotingand managing player behaviors (e.g., information about the player'sgaming preferences, lodging arrangements, and the like). Further, theplayer database may store data regarding a given player's standing in agame session and/or a bonus game. A player database may also storeinformation regarding DVDs previously purchased, ordered and/or redeemedby a player. Such player data may be stored in a relational database andretrieved or otherwise accessed by the processor after receiving a “key”data point from the player, such as a unique identifier read from theplayer's player tracking card or cashout ticket.

In one embodiment, the player tracking device 660 may comprise (i) acard reader (e.g., a port into which player tracking cards may beinserted), (ii) various input devices (e.g., a keypad, a touch-screen),(iii) various output devices (e.g., a small, full-color display screen),and/or (iv) combinations thereof (e.g., a touch-sensitive display screenthat accommodates both input and output functions). Various commerciallyavailable devices may be suitable for such an application, such as theNextGen™ interactive player tracking panel manufactured by IGT™ or theiVIEW™ display screen manufactured by Bally Gaming and Systems™.

As known in the art, “smart cards” may incorporate (i) a memory, and(ii) means for accessing such a memory. For example, in one embodiment,the memory may store data related to embodiments of the presentinvention. In one embodiment, data may be written to the smart card as aplayer plays one or more GDs (e.g., such that various data may beupdated on a continuous, periodic or event-triggered bases).Accordingly, in one or more embodiments one or more devices operable tocarry out various processes of the present invention (e.g., a GD 600, CS305 and/or AS 310) may have associated therewith a smart card readerdevice, such that data may be read from the smart card pursuant to theexecution of such processes. An example of a smart card system that maybe used to implement one or more embodiments of the present invention isthe s-Choice™ Smart Card Casino Management System from Smart CardIntegrators, Inc.™.

Of course, other non-card-based methods of identifying players arecontemplated. For example, a unique identification code may beassociated with the player. The player may then be identified uponentering the code. For example, the code may be stored (e.g., within adatabase maintained within a GD 600 and/or CS 305) such that the playermay enter the code using an input device of a GD, and accordingly allowthe player to be uniquely identified. In other embodiments, playerbiometrics may serve as identification means (e.g., a player isidentified via a thumbprint or retinal scan of the player). In furtherembodiments, a barcode of a cashless gaming ticket may encode a playeridentifier.

Thus, as described, various data associated with a player may be trackedand stored (e.g., in an appropriate record of a centrally-maintaineddatabase), such that it may be accessed as desired. Further, variousstatistics may be measured in association with a player (e.g., coin-instatistics, win/loss statistics, buy-in amount for a play session) andsimilarly accessed.

Various systems for facilitating such monitoring of player behavior andactivity are contemplated. For example, a two-wire system such as oneoffered by IGT™ may be used. Similarly, a protocol such as the IGT™ SAS™protocol or the IGT™ SuperSAS™ protocol may be used. The SAS™ protocoland the SuperSAS™ protocol each allows for communication between gamingmachines and slot accounting systems and provides a secure method ofcommunicating all necessary data supplied by the gaming device to theonline monitoring system. One aspect of the SAS™ protocol and theSuperSAS™ protocol that may be beneficial in implementing aspects of thepresent invention is the authentication function which allows operatorsand regulators to remotely interrogate gaming devices for importantmemory verification information, for both game programs, and peripheraldevices. In another example, a one-wire system such as the OASIS™ Systemoffered by Aristocrat Technologies™ or the SDS™ slot-floor monitoringsystem offered by Bally Gaming and Systems™ may be used. Each of thesystems described above is an integrated information system that (e.g.,continually) monitors slot machines and customer gaming activity. Thus,for example, any one of these systems may be used to monitor a player'sgaming activity in order to determine player outcomes, buy-in amounts,coin-in statistics, win/loss statistics and/or any other data deemedrelevant.

In one embodiment, a player may operate a plurality of GDs. For example,a player may simultaneously play two side-by-side GDs, a player may playone GD and then continue his gaming session at another GD, and a playermay remotely operate a GD, possibly by using a telephone, PDA or otherdevice (i) to transmit commands (directly or indirectly) to the GD, suchas wager amounts and commands to select certain cards; and/or (ii) toreceive output (directly or indirectly) from the GD.

In one embodiment, a GD may allow a player to play a game of skillrather than a game of chance. Such an embodiment may be more appealingto certain players or may be permitted in areas where it is illegal togamble on games of chance.

In one embodiment, GD 600 may be operable to facilitate downloadablegames such that games available for play on GD 600 may be stored on aserver device (e.g., CS 305 or another device) and downloaded to the GD600. In one embodiment, software components of GD 600 may be remotelymodified and/or updated by another device (e.g., CS 305 or anotherdevice). For example, a payout or probability table stored in the memoryof GD 600 may be altered, modified or updated remotely, hot fixes may beapplied to software stored by GD 600 and/or new versions of software maybe downloaded to GD 600. Similarly, GD 600 may be programmed to retrieveany or all such updates from another device, as appropriate andpreferred. Any of the above (e.g., downloading of a game, updating ofsoftware, modification of a payout or probability table) may occur, forexample, based upon an occurrence of an event (e.g., a scheduled event),an indication being received from qualified casino personnel or otherpersonnel (e.g., a regulator), and/or upon a request from a player. Inone embodiment, GD 600 may comprise a thin client device controlled be aserver device (e.g., CS 305 or another device).

In one or more embodiments, aspects of the present invention, such asgenerating a plurality of outcomes for storage on a DVD, may bepracticed by replacing and/or augmenting one or more components (e.g.,hardware and/or software components) of an existing GD. Thus, in one ormore embodiments, embodiments may be applied as a retrofit or upgrade toexisting GDs currently available for play within various casinos.

For example, a memory (e.g., computer chip) of GD 600 may be replaced oradded, the replacement or additional memory storing a program forinstructing the processor of GD 600 to operate in accordance with one ormore embodiments. In another example, data output via GD 600 (e.g.,graphical and/or textual data displayed on GD 600) may be replaced oradded, the replacement or additional data indicating to a playerinformation relevant to one or more aspects of the present invention.

In a specific example, GD 600 may comprise various electronic componentsmounted to one or more printed circuit boards (PCBs). Such componentsmay include various hardware described herein, such as a communicationsport and various controllers of peripheral devices (e.g., a displaycontroller), as well as a memory for storing programming instructions(software) and a processor for carrying out such instructions. Forms ofmemory that may be found in a gaming device include electronicallyerasable programmable read-only memory (EEPROM), erasable programmableread-only memory (EPROM) and flash memory. Thus, in one or moreembodiments of the present invention, an EPROM storing software withinstructions for carrying out aspects of the present invention (as wellas instructions for carrying out other functions traditionally performedby the GD) may replace an EPROM previously installed in GD 600 or may bereprogrammed in accordance with one or more embodiments describedherein, such that GD 600 may be configured to operate in accordance withvarious processes (or portions thereof) described herein.

For example, a “DVD outcome generation” module may be made available forpurchase to various casino operators. The module, which may comprisevarious hardware and software (e.g., an EEPROM storing softwareinstructions), may be installed in an existing GD (e.g., a video-reelslot machine, a video poker machine, etc.), such that when the module isinstalled, players of the device may elect (i) to play the GD in amanner that does not incorporate embodiments described herein, or (ii)to play the GD in a manner that incorporates embodiments describedherein (e.g., input a request for a plurality of outcomes to begenerated and stored on a DVD, for future viewing at a remote location).

Similarly, in addition to or in lieu of a player being able to select amode of operation of the GD, in some embodiments a casino operator maybe able to do so. For example, a casino operator or other entity may beable to select whether the GD is to operate in a conventional mode or ina “DVD outcome generation” mode.

Accordingly, a GD may be configured to allow a player, casino operatoror other entity to select one of at least two “modes” of the GD and toenable the selected mode. If a “standard” mode is selected, the GD maybe configured to operate in a manner similar to how it operated beforethe installation of the module (e.g., the GD operates in a conventionalmanner, such that embodiments described herein may not be utilized). Ifa “DVD outcome generation” mode is selected, the gaming device may thenbe operable to execute game play in accordance with one or moreembodiments described herein.

In one example of allowing an entity to select one or more modes, atouch-sensitive display screen may be configured to output a prompt toselect a mode of operation. Such a prompt may be output upon occurrenceof any of various trigger conditions (e.g., coins, bills or tickets areinserted; a credit balance increases from zero to some other number; aplayer presses a “play” button; a motion, weight, infrared or othersensor detects the presence of a player; the gaming device being turnedon, initiated, re-configured and/or rebooted, etc.). Accordingly, anentity may select a mode of operation (e.g., by pressing anappropriately labeled icon of a touch-sensitive display screen), andupon receiving the entity's selection, the GD may be configured tooperate in the selected mode.

In another embodiment, a GD may be operable to automatically determinewhether it should switch modes from a standard mode to a “DVD outcomegeneration” mode. A GD may perform such a determination, for example, byevaluating data received from a player and/or another device and/or byquerying another device. For example, a GD may be operable to enter a“DVD outcome generation mode” upon an occurrence of one or morepredetermined events and/or upon determining that one or morepredetermined conditions have been satisfied. For example, a GD may beoperable to enter a “GD outcome generation mode” upon an occurrence of apredetermined time, if the GD is idle during that time (e.g., between 2am and 7 am) and/or upon being directed to do so by another device(e.g., by CS 305).

In one embodiment, a GD may be operable to output an indication that itis currently in “DVD outcome generation” mode (e.g., to inform a playerthat outcomes currently being generated by a gaming device are for a DVDto be made available for sale or a DVD that has been requested). Forexample, the GD may turn on or change a color of a light, changegraphics, output a sound, etc.

In other embodiments, as described herein, a peripheral device may beuseful for implementing one or more embodiments of the present inventioninto the operation of a GD. For example, in order to avoid or minimizethe necessity of modifying or replacing a program already stored in amemory of a GD, an external or internal module that comprises aperipheral device may be inserted in, connected to or otherwiseassociated with the GD. Such a peripheral device may be operable to, forexample, monitor and/or transmit information about the gaming device toanother device (e.g., CS 305).

In still further embodiments, rather than (or in addition to)configuring a GD to execute embodiments described herein by physicallyinstalling or connecting new hardware and/or software, software may bedownloaded into an existing memory of one or more GDs. U.S. Pat. No.6,805,634 to Wells et al. teaches methods for downloading data to GDs insuch a manner. The entirety of U.S. Pat. No. 6,805,634 is incorporatedby reference herein for all purposes. Thus, in some embodiments, a GDmay be reprogrammed to accommodate new functionality of the presentinvention without the need, or by minimizing the need, to remove andreplace hardware within the GD.

In some embodiments, a GD comprises a “simplified gaming device” or SGD.An SGD, as the term is used herein, may comprise a device operable togenerate an outcome based on a random number but that is not designed tobe located on a casino floor for interaction with a player. For example,an SGD may be programmed to perform functions different from that of amore conventional type of GD and/or to not perform some of the functionsconventionally performed by a GD (e.g., display an indication of anoutcome determined based on a random number). Further, a SGD may includecomponents different from those normally included in a more conventionaltype of GD and/or fewer such components. For example, in someembodiments an SGD may not include a benefit output device 640 and/orplayer tracking device 660. For example, in some embodiments Applicantsenvision that a plurality of outcomes for storage and sale via a DVD maybe generated by a SGD that comprises a processor running in conjunctionwith an emulator of a wagering game, the SGD being located in a locationother than a casino floor frequented by players. Such an SGD may not,for example, include a cabinet designed to attract a player and may notbe operable to output coins, tokens or other benefits. Such an SGD may,however, be programmed to generate a large number of outcomes (e.g.,substantially simultaneously) without displaying any of the outcomes sogenerated, which is unlike a conventional type of gaming device.

4. Databases

Various databases that may be useful in one or more embodiments will nowbe described. Example structures and sample contents of each of (i) thesession database 425, (ii) the gaming device database 430, (iii) thereference session results database 435, (iv) the active sessionsdatabase 440, (v) the available DVDs database 445, (vi) media filedatabase 525, (vii) session media file database 530, (viii) DVDproduction queue database 535, (ix) outcome sets database 540, (x)probability database 620, and (xi) payout database 625 are shown inFIGS. 7 through 16. The specific data and fields illustrated in thesedrawings represent only some embodiments of the records stored in thedatabases described herein. The data and fields of these databases canbe readily modified, for example, to include more or fewer data fields.A single database also may be employed to combine one or more of thesedatabases. Note that in the databases, a different reference numeral isemployed to identify each field of each database. However, in at leastone embodiment, fields that are similarly named (e.g., sessionidentifier fields) may store similar or the same data in a similar or inthe same data format.

As will be understood by those skilled in the art, the schematicillustrations and accompanying descriptions of the sample databasespresented herein are exemplary arrangements for stored representationsof information. Any number of other arrangements may be employed besidesthose suggested by the tables shown. For example, even though ten (10)separate databases are illustrated, the embodiments described hereincould be practiced effectively using fewer or more functionallyequivalent databases. Similarly, the illustrated entries of thedatabases represent exemplary information only; those skilled in the artwill understand that the number and content of the entries can bedifferent from those illustrated herein. Further, despite the depictionof the databases as tables, an object-based model could be used to storeand manipulate the data types of one or more embodiments and likewise,object methods or behaviors can be used to implement the processes ofone or more embodiments.

Referring now to FIG. 7A, illustrated therein is a tabularrepresentation 700A of an embodiment of a record of session database425, such as may be stored in a memory of CS 400 and/or a memory ofanother device. Tabular representation 700A is referred to herein assession database record 700A.

Session database record 700A includes a number of example records orentries, including entries R700A-1 through R700A-9, each defining a gameplay of a particular session. Those skilled in the art will understandthat the record 700A may include any number of entries.

The session database record 700A also defines a number of fields. Thefields specify: (i) a unique session identifier 705A; (ii) a wageramount per game play 710A (e.g., a specific wager per game play whereinthe wager is the same for each game play of the session, an averagewager per game play, etc.); (iii) a game 715A that specifies a game forwhich the game plays of the session are conducted; (iv) a sessionduration 720A that defines a duration of the session or an end eventthat causes the session to end; (v) a price 725A to be paid in exchangefor the game plays of the session; (vi) a final session balance 730Athat may comprise an indication of a number of credits or monetary valueof a credit meter balance upon completion of a session (also referred toas an end credit meter balance herein); (vii) a game play number 735Athat identifies each particular game play of the session; (ix) a wager740A that was posted for each particular game play (if the wager pergame play does not vary, this field may be omitted in light of field710A); (x) an indicia 745A that is determined as a result of each gameplay; (xi) an indicia identifier 750A that identifies (e.g., uniquely)the indicia of field 745A (alternatively, this may be an outcomeidentifier); and (xii) a payout 755A that corresponds to a benefit,prize or monetary value won as a result of a corresponding game play.

In one embodiment, a session identifier may comprise indications ofvarious session result data. For example, an indication of a payoutamount, outcome identifier, wager amount, game play number, sessionidentifier and/or other information related to a session may be includedin or discernable from a session identifier. For example, a sessionidentifier “01927-012-01-25-000001-0” may indicate that a first gameplay of contract “01927” occurred on GD “012” with a wager amount of“25,” yielding an outcome of “000001” and a payout of “0”.

It should be noted, with respect to fields 745A and 750A, that theindicia and indicia identifier may correspond to indicia determined by aGD based on a random number determined for the corresponding game play(e.g., using a payout table such as the one illustrated in FIG. 16). Forexample, the record 700A may be populated by a GD 600 and/or CS 400based on the outcome determined for each game play of a session. Inother embodiments, the indicia in field 745A and indicia identifier 750Amay correspond to indicia determined for a representative outcome, asdetermined by a device other than a GD (e.g., as determined by AS 310).For example, the session database record 700A may be utilized by AS 310to store the indicia determined for each game play of a session based onan indication of a plurality of outcomes (e.g., an indication of aresult of a session) received by AS 310. In some embodiments, both anindication of indicia of an actual outcome and an indication of indiciaof a representative outcome may be stored for a particular game play.

It should further be understood that the payout of field 755A maycomprise a payout as determined by a GD based on a random number. Forexample, the record 700A may be populated based on the payouts asdetermined by the GD. It should be noted that, in some embodiments, avideo presentation of payouts may be created based on the data in record700A. In such embodiments, the order in which payouts are presented viathe video presentation may differ from the order in which the payoutsare stored in record 700A and/or the order in which the payouts weredetermined by a GD.

In some embodiments, the payout field 755A may store payouts asdetermined by another device (e.g., AS 310) based on an indication of aplurality of outcomes (e.g., based on an indication of a result of asession). For example, as described in detail herein, in someembodiments AS 310 may receive an indication of (i) a beginning creditmeter balance for a session; (ii) an ending credit meter balance for thesession; (iii) an indication of wagers posted for the session; and (iv)a number of game plays comprising the session. The AS 310 may thendetermine a plurality of payouts and, in some embodiments, the order inwhich the payouts are to be presented via a video presentation, based onsuch data. Accordingly, in such embodiments AS 310 may utilize sessiondatabase record 700A to store the determined payouts and/or the order ofthe payouts as they are to be presented via a video presentation.

It should be understood that a payout field in any of the databasesdescribed herein may store a value of a payout amount corresponding to aparticular outcome and it may be stored in any form practicable anddesirable. For example, a payout value may be represented as a number ofcredits. Alternatively, a payout value may be stored to represent adollar value.

Accordingly, it should be understood that in various embodiments thesession database record 700A may be populated by a GD, a CS and/or a AS.Further, it should be understood that in various embodiments the record700A may be utilized by a GD, CS and/or AS for different purposes. Forexample, a GD and/or CS may utilize record 700A to store an actualoutcome of each game play of a session. In another example, an AS mayutilize record 700A to store representative outcomes determined for asession.

Referring now to FIG. 7B, illustrated therein is a tabularrepresentation 700B of an embodiment of a record of session database425, such as may be stored in a memory of CS 400 and/or a memory ofanother device. Tabular representation 700B is referred to herein assession database record 700B.

In particular, session database record 700B includes information about aplurality of players associated with the same session (e.g., for asingle DVD or game disc). It will be readily understood that a sessionfor a plurality of players may comprise outcomes and/or payoutsdetermined in two or more respective sessions (e.g., gaming sessionsexecuted at different gaming devices, or otherwise separate from oneanother). In some embodiments, discussed herein, sessions may beinterdependent (e.g., for some types of multiplayer games). Thus, insome embodiments a session may comprise two or more other sessions. Insome embodiments, such a session may be referred to as a reference run,in which a plurality of sessions are executed (e.g., using the sameparameters and corresponding values).

Session database record 700B includes a number of example records orentries, including entries R700B-1 through R700B-9, each defining a gameplay of a particular session. Those skilled in the art will understandthat the record 700B may include any number of entries.

The session database record 700B also defines a number of fields, mostof which are similar to those described with respect to database record700A (e.g., field 710A corresponds to field 710B of record 700B, and soon). In addition, session database record 700B includes respective finalsession balances 730B, 732B, and 734B for each of the “RED,” “BLUE,” and“GREEN” players (e.g., simulated players who will be represented on aDVD as being associated with respective images of credit meters, slotindicia, credit meters, etc.). In the example session database 700B, the“GREEN” player has the highest final session balance, and thus may beeligible to collect some redemption value for the session, as discussedherein. Of course, in accordance with various embodiments, any number ofthe plurality of players may be eligible to redeem some value, based onthe particular rules and criteria for the purchased product.

Session database record 700B further includes player identifier 738B,which includes an identifier that identifies which player (e.g., a realor simulated player) is associated with the corresponding game play.Although fictitious player labels (e.g., “RED”) are used in the sessiondatabase record 700B, it will be readily understood that suchidentifiers may include, for example, the name of an actual player(e.g., one who requested the session), or some other identifier thatidentifies an actual player. In some embodiments, the associatedsimulated players may have names of actual people (e.g., celebrities,popular card players)-some types of purchasers may find it desirable,for example, to purchase a product in which play is simulated as if byfamous individuals.

Referring now to FIG. 8, illustrated therein is a tabular representation800 of an example embodiment of gaming device database 430, as it may bestored in a memory of CS 400 and/or a memory of another device. Tabularrepresentation 800 is referred to herein as GD database 800.

The GD database 800 includes a number of example records or entries,including records R800-1 through R800-n, each defining a gaming devicethat may be in communication (e.g., over a LAN or WAN) with CS 305 orotherwise available for embodiments of the present invention. Thoseskilled in the art will understand that the GD database 800 may includeany number of entries. The GD database 800 also defines fields for eachof the entries or records. The fields specify: (i) a gaming deviceidentifier 805 that uniquely identifies a particular gaming device(e.g., uniquely identifies a particular slot machine on a casino flooror a PC communicating with an online casino), (ii) a gaming device type810 that stores a description or designation of the type of gamingdevice, (iii) a gaming device status 815 that stores an indication ofthe corresponding gaming device (e.g., whether the gaming device iscurrently being used or not, whether the gaming device is off-line oron-line, whether the gaming device is available to generate outcomes fora DVD, etc.); and (iv) available games 820 that stores an indication ofthe one or more games the corresponding gaming device is operable tofacilitate or run. It should be noted that, as with any databasedescribed herein, any and all of the information stored in a field ofthe database may be stored in machine-readable format and/orhuman-readable format (which, in certain circumstances, may be the sameformat).

The GD database 800 may be used, for example, to communicate with one ormore GDs and to identify a GD that data is being transmitted to orreceived from (e.g., based on the GD identifier). In one embodiment, theGD database 800 may be used to select a particular GD, in order todirect the GD to generate a plurality of outcomes for a DVD. Such aselection may be made, for example, based on a type of GD desired (e.g.,five reeled slot machine or video poker machine), a current status ofthe GD (e.g., currently inactive but turned on and operational), and/orthe games available on the GD. Of course, information in addition to ordifferent from that illustrated in GD database 800 may be stored in a GDdatabase. For example, a location of a GD (e.g., to allow a casinoemployee to find the GD), an address for electronically communicatingwith the GD may be stored (e.g., for use in directing the GD to performcertain functions) and/or a manufacturer of the GD may be stored.

Referring now to FIG. 9, illustrated therein is a tabular representation900 of an example embodiment of an active sessions database 435 (e.g.,such as one that may be stored in a memory of a CS 400 or a memory ofanother device). Tabular representation 900 is referred to herein asactive sessions database 900.

The active sessions database 900 includes a number of example records orentries, including records R900-1 through R900-4, each defining asession that is currently active (e.g., is in the process of beingexecuted or has been scheduled to be executed). Those skilled in the artwill understand that the active sessions database 900 may include anynumber of entries. The active sessions database 900 also defines fieldsfor each of the entries or records. The fields specify: (i) a sessionidentifier 905 that uniquely identifies a session; (ii) a GD identifier910 that identifies a GD or type of GD on which the session is to beexecuted (which, in some embodiments, may include a plurality of GDs ortypes of GDs); (iii) a game type identifier 915 that identifies the gamefor which the outcomes of the session are to be determined; (iv) a wagerper game play 920; (v) active payout combinations 925; (iv) a number ofgame plays remaining 930 (which may, in other embodiments, store anotherindication of a remaining duration of the corresponding session); and(v) a time remaining 935 that stores an indication (e.g., estimate) ofhow much time remains before the session is completely executed.

The active sessions database 900 may be utilized, for example, to trackinformation about sessions that have begun to be executed and/or thatare scheduled to be executed on a GD. For example, a GD or CS may usesuch a database to track an indication of results of a session. Once thesession has been completed, the GD or CS may then communicate theindication to an AS.

Referring now to FIG. 10, illustrated therein is a tabularrepresentation 1000 of an example embodiment of an available DVDsdatabase 440 (e.g., as it may be stored in a memory of a CS 400 and/orin a memory of another device). Tabular representation 1000 is referredto herein as available DVDs database 1000.

The available DVDs database 1000 includes a number of example records orentries, including records R1000-1 through R1000-6, each defining a DVDthat is available for purchase or that was available for purchase. Thoseskilled in the art will understand that the available DVDs database 1000may include any number of entries. The available DVDs database 1000 alsodefines fields for each of the entries or records. The fields specify:(i) a disc identifier 1005 that uniquely identifies a DVD; (ii) aredemption value 1010 that indicates a payment that may be provided to aplayer who purchases the corresponding DVD, upon redemption of the DVD;(iii) a price 1015 to be paid by a player for the DVD; (iv) a date sold1018 that indicates a date and/or time on which the corresponding DVDwas sold; (v) an activation code 1020 that may be provided, in someembodiments, to a player upon the player purchasing the DVD; (vi) aplayer identifier 1025 that identifies one or more players who purchasesthe corresponding DVD (in some embodiments DVDs may be purchasedanonymously and this information may not be stored) and/or one or moreplayers otherwise associated with the DVD (e.g., a person who did notactually purchase the DVD may be potentially be eligible to receive someor all of the redemption value of the DVD by registering as a player ofthe DVD); and (vii) a status 1030 of the DVD (e.g., an indication ofwhether the DVD is “available” for purchase or otherwise available to beprovided to a player, has been “purchased” or otherwise provided to aplayer, or has been “redeemed” such that the redemption value of theDVD, if any, has been provided to a player).

The available DVDs database 1000 may be utilized, for example, to trackDVDs available for purchase at a casino. For example, as a DVD isprovided by AS 310 or otherwise made available for sale or otherprovision to a player, a new record may be created in the database basedon the unique DVD identifier of the DVD. The redemption value associatedwith the DVD may also be recorded in the newly created record (e.g., theredemption value that corresponds to the DVD identifier may be receivedfrom AS 310). The status of the DVD may be set to “available.”

In one embodiment, the available DVDs database 1000 may be utilizedagain when a player requests to purchase a DVD. For example, thedatabase may be queried based on the DVD identifier on the packaging ofthe DVD that the player desires to purchase. It may be verified that theDVD has not previously been purchased, based on the status 1030associated with the DVD in the database. Further, an activation code maybe determined (e.g., by CS 305, which may generate or select anactivation code for each DVD as it is sold via a POS 320) and theactivation code may be recorded in the appropriate record of theavailable DVDs database. For example, POS 320 may communicate with CS305 in order to determine the activation code and verify that the DVD isavailable for purchase.

It should be noted that an activation code may, in some embodiments, benecessary to activate a DVD (e.g., the player may be required to inputthe activation code when inserting the DVD into a DVD player). In otherembodiments, the activation code may only be necessary for redemption ofthe DVD but not for viewing the video presentation of the DVD. Theactivation code may also be printed on a receipt provided to the playerfor the purchase of the DVD, or otherwise provided to the player uponthe DVD being provided to the player in a legitimate manner.

The available DVDs database 1000 may be accessed yet again when one ormore players attempt to redeem a DVD (e.g., collect the redemption valueassociated with the DVD). For example, as described in detail herein(e.g., particularly with reference to FIG. 27), it may be verified thatthe DVD was legitimately purchased and that the DVD has not previouslybeen redeemed (e.g., the status associated with the DVD is “purchased”).

With respect to entry R1000-6, it should be noted that a plurality ofplayers are associated with the corresponding disc “D-153478-567481254.”In some embodiments, the available DVDs database 1000 may store anindication of which at least one of a plurality of associated playershas redeemed some value associated with the DVD (e.g., in status 1030).

Referring now to FIG. 11A, illustrated therein is a tabularrepresentation 1100A of an example embodiment of a record of a mediafile database 525 (e.g., as it may be stored in a memory of AS 500and/or a memory of another device). Tabular representation 1100A isreferred to herein as media file record 1100A.

The media file record 1100A includes a number of example entries,including entries R1100-1 through R1100-9, each defining a media fileavailable for inclusion in a video presentation depicting outcomes for asession (e.g., a current session). The term “current session,” as usedwith respect to the description of FIG. 11A, refers to a session forwhich a video presentation is currently being created based on theinformation in media file record 1100A.

Those skilled in the art will understand that the media file record1100A may include any number of entries. The media file record 1100Aalso defines fields for each of the entries or records. The fieldsspecify:

(i) a game 1105A that indicates a game to which the media filescorrespond (e.g., the identifier may be in an alphanumeric or text form;the identifier may be in machine and/or human readable form; theidentifier may comprise a brand name of a game (e.g., IGT™ DoubleDiamonds™ game) or another identifier that uniquely identifies the gamewithin a system);

(ii) a game type file 1110A, which stores a media file comprising dataindicating a type of game for which the outcomes of a current sessionwere determined (e.g., reeled slot machine vs. draw video poker or3-reeled slot machine vs. 5-reeled slot machine);

(iii) a game brand file 1115A, which stores a media file comprising dataindicating a brand of the game (e.g., a logo of the manufacturer of thegame and/or a logo of the title of the game) for which the outcomes of acurrent session were determined;

(iv) a casino brand file 1120A, which stores a media file comprisingdata indicating a casino at which the outcomes of a current session weredetermined and/or a casino that ordered the DVD corresponding to thesession (e.g., the logo of the casino, an aerial shot of the casino, adrawing or picture of the outside of the casino, etc.);

(v) an outcome identifier 1125A that uniquely identifies an outcome;(vi) an outcome 1130A that describes the set of indicia corresponding tothe outcome identifier;

(vii) an outcome media file 1135A that stores a media file comprisingdata indicating the outcome corresponding to the outcome identifier(e.g., an animation of the appropriate number of reels starting to spinfrom a stopped position and stopping to depict the appropriate symbolsalong a payline, accompanied by appropriate sounds of the slot machine);

(viii) a duration 1140A that indicates a duration of the correspondingoutcome media file.

It should be understood that, with respect to fields 1110A, 1115A, 1120Aand 1135A, in one embodiment, the fields may store one or more of (i)the files themselves; (ii) an indication of where a file is stored(e.g., a file path); (iii) video and/or audio data; (iv) a large filename plus start/stop time codes for the file, such that the large filemay include an indication of a plurality of outcomes and the start/stoptimes may be used to select the particular portion of the large filethat depicts the desired outcome.

It should be understood that, in some embodiments, AS 500 may beoperable to manufacture multiple video sessions and/or multiple DVDssimultaneously.

A media file may comprise graphical and/or audio data. Further, thegraphical data may be still and/or animated.

The duration 1140A of a media file may vary from a first outcome to asecond outcome. For example, outcomes corresponding to larger payoutsmay comprise a longer duration that includes a longer pause at the endof an animation showing the reels stopping to display a winningcombination of symbols along a payline, to allow a player to enjoy thewin and/or to help ensure that the player recognizes the win.

The media file record 1100A may, in some embodiments, include differentand/or additional data. For example, a media file depicting the wageramount per game play may be stored. In another example, an indication ofthe number of frames included in each media file may be stored.

The number of frames information may be used, for example, to determinea portion of a media file into which another media file may be overlaid.For example, in some embodiments a changing credit meter balance may beindicated during each represented game play. For example, for a reeledslot machine game, each time an outcome is revealed during thepresentation by depicting an animation of reels spinning, a media filecomprising a credit meter balance value may be overlaid in a specificportion of each frame, and the credit meter balance may be depicted aschanging within a certain number of frames from the beginning of themedia file depicting the spinning reels. For example, assuming a mediafile depicting the spinning reels is 900 frames long, at the 50^(th)frame, an overlay of the credit meter balance graphic may be depicted asdecreasing due to the wager posted for the game play and, during the800^(th) frame, the overlay of the credit meter balance graphic may bedepicted as increasing due to a payout won, if any, as a result of thegame play. Accordingly, a program for creating the video presentationmay be programmed to overlay certain graphics at certain frames of amedia file.

The media file record 1100A may, in some embodiments, includeinformation related to one or more players. For example, the media filerecord 1100A may include an indication of a number of players depictedin one or more media files. In another example, an indication oridentification of one or more (e.g., real, fictitious, or simulated)players represented in each media file may be stored. For instance, anentry may include an indication that the corresponding media filerepresents respective outcomes allocated to two simulated playersidentified as “RED PLAYER” and “BLUE PLAYER.”

The media file record 1100A may be accessed, for example, by AS 500 toselect media files to include in a video presentation. For example, inone embodiment AS 500 may access the record 1100A and select media filesbased on session result information for a particular session receivedfrom CS 305 or another device. For example, the AS 500 may determine,from the session result information, the game for which outcomescomprising the session were determined. The AS 500 may thus select theappropriate record of a media file database based on the game (i.e., insome embodiments each record may correspond to a different game). The AS500 may then create a video presentation by putting together thefollowing media files in the following order: (i) the game type file;(ii) the game brand file; (iii) the casino brand file; and (iv) theappropriate outcome media files, selected based on the outcomesdetermined for the session and put together in an appropriate order. Theoutcomes depicted in the outcome media files may be referred to as therepresentative outcomes for the session.

With respect to item (iv), as described in detail herein, in someembodiments the outcomes for the session may be selected by AS 500 basedon session result information or an indication of a plurality ofoutcomes determined for the session. Similarly, in some embodiments theorder of the outcomes may be selected by AS 500. Accordingly, AS 500 mayperform a routine for selecting the outcomes (e.g., outcome identifiers)and order thereof prior to accessing the media file database. In otherembodiments, the outcomes and/or order thereof may be determined byanother device (e.g., CS 305 or GD 315). In such embodiments, AS 500 mayaccess the media file database to select the appropriate outcome mediafiles and the order in which they should be put together in the videopresentation based on the received information that indicates theparticular outcomes and particular order thereof.

In some embodiments, media files of additional information may be storedin media file record 1100A. For example, a media file depicting a payoutschedule active for a current session may be stored. In another example,a message congratulating a player on obtaining a particularly largepayout (e.g., a payout greater than 100 credits) may be depicted in amedia file. Accordingly, in some embodiments AS 500 (or another deviceoperable to create a video presentation for a session) may be programmedto select such a media file and place it in the video presentation in anappropriate location (e.g., immediately following a media file depictingthe particularly large payout). In some embodiments such messages may begeneric such that they are not dependent on the player(s) or number ofplayers depicted in the video presentation, and/or not dependent on thegame or game type being played. Accordingly, in such embodiments suchmessages may be stored in a distinct database that is accessed by AS 500as appropriate.

It should be noted that, in creating a video presentation based on mediafiles, the media files may not necessarily be put together in asequential order such that only a single media file is depicted at anygiven time, followed by another media file. The media files may be puttogether in any manner that is desirable and practicable (e.g., themedia files may be overlaid together, merged, depicted simultaneously ona screen, etc.). For example, some media files (e.g., payout schedulemedia file, casino brand media file, wager per game play media file,game brand media file) may be depicted in one or more frames or portionsof frames of one or more media files (e.g., along with each outcomemedia file). For example, a video presentation may be created such thatthe casino logo, game logo, credit meter balance graphic and/or a numberof spins remaining graphic is always displayed along a portion of thescreen as the animation of reels spinning to reveal an outcome isdepicted along another portion of the screen.

In some embodiments, the overlay of a graphic or first media file ontoone or more frames (or portions of a frame) of a second media file maybe performed during the production process (e.g., as the videopresentation and corresponding DVD are being created). In otherembodiments, the appropriate information may be stored on a DVD and anappropriately programmed DVD player in a player's home may be operableto overlay the information when playing the video presentation.

In some embodiments, distinct media files depicting outcomes may becreated for each casino or other customer who may order a DVD inaccordance with embodiments described herein. For example, a particularoutcome for a Double Diamonds™ machine at Stallion casino may be storedin a distinct media file from the same outcome for a Double Diamonds™machine at the French Riviera™ casino. This may save resources (e.g.,time) producing a DVD in that a graphic of the game brand and/or casinoneed not be overlaid onto each frame or media file depicting an outcome.Rather, the appropriate record for the appropriate combination of gamebrand and casino may be accessed to determine the media files to be usedin creating the video presentation, and the media files may already becustomized for the game brand and/or casino. In such embodiments, thegame brand file 1215 and/or the casino brand file 1220 may include anidentifier of a game brand and/or an identifier of a casino brand, forpurposes of accessing the appropriate record.

In some embodiments, an indication of a payout corresponding to each setof indicia comprising an outcome may also be stored in table 1100A. Inother embodiments, the corresponding payout (e.g., for determined how toadjust a credit meter balance graphic) may be stored in a separatedatabase (e.g., the payout may be determined based on the outcomeidentifier, wherein the subject database correlates each payout to anoutcome identifier).

Of course, it should be understood that more than one such media filemay be associated with an outcome identifier, and that a variety of suchmedia formats are contemplated. For example, in one embodiment, filesindicated and stored by a media file database may be of a formatcommonly used for storing video on a DVD. Other formats for digitallystoring video or audio/video (e.g., MPEG, MPEG2, AVI, MOV, DivX, etc.)are contemplated, as well as other formats for storing audio (e.g., MP3,WAV, etc.). Such media files may comprise video animations, videorecordings or any other graphic renderings that otherwise recreate orapproximate the entertainment that a GD commonly outputs whencommunicating game results. For example, if an outcome of a GD is“BELL-BELL-BELL,” a media file corresponding to the outcome (or aplurality of media files that are overlaid, interlaced or otherwisecombined to represent the outcome) may comprise a graphic animation ofthe spinning reels, changes in credit balance and other visuals commonlyoutput by a display screen of the GD, as well as accompanying soundeffects. In another example, a media file may comprise a video recordingof an actual GD producing such a game result (e.g., a video camera isused to capture the GD outputting such a result). Various combinationsand modifications of such embodiments are also contemplated.

Additionally, it should be understood that such a media file databasemay be structured in a variety of manners. For example, rather thanstoring outcome identifiers and associated media files as records ofentry associated with a particular game, outcome identifiers themselvesmay comprise an embedded indication of a game (e.g., an outcomeidentifier is “GD-BTO-012-O-000001” or “012-000001,” with “GD-BTO-012”or “012” identifying a game for which the outcome was generated), suchthat a media file database need not comprise separate entries for eachof a plurality of possible games.

It should also be noted that in the above-described embodiment, eachnon-winning outcome is represented by the same outcome identifier (e.g.,“BELL-BAR-ORANGE” is the same as “7-BAR-PLUM”). Of course, alternativemethods of representing such outcomes are contemplated (e.g., eachnon-winning outcome and winning outcome is associated with a uniqueoutcome identifier). Further, it should be understood that various“substitute” or “alternate” media files may be used in place of anidentified outcome. For example, a database may indicate a number ofappropriate media files from which one may be selected randomly (orbased on another rule) to represent the identified outcome.

In one embodiment, only payout (and, in some embodiments, game playnumber) information associated with a session may be utilized (e.g., byAS 500) in creating a video presentation to be recorded onto a DVD. Forexample, session result data may indicate only that a first game playyielded a payout of 0 coins, a second game play yielded a payout of 5coins, and so on. In this manner, AS 500 may select from a variety ofappropriate media files (e.g., media files may be archived according tothe occurrence of a payout amount that the file represents). Such anembodiment may be beneficial in that, for example, AS 500 may choose oneof a variety of different gaming device “skins” or visual motifs whendetermining a media file associated with an outcome (e.g., AS 500 mayselect a media file themed after a slot machine a player has indicated apreference for). Such an embodiment is described below with reference toembodiment 1100B of a media file database.

Still further methods of determining media files pursuant to creating avideo presentation of session are contemplated. In one embodiment,rather than determine an associated media file based on an outcomeidentifier or other identifier, AS 500 may simply access, in associationwith a session, (i) a game play number and (ii) an associated mediafile. For example, in some embodiments, in outputting session resultdata (e.g., to a session database 425 and/or to a printed ticket), a GDmay simply output (i) a session identifier, (ii) one or more game playnumbers, and (iii) one or more associated media files. In this manner,AS 500 may determine which media files are to be used in the creation ofa video presentation without, for example, the need access a databasesuch as a media file database 525. For example, simply by scanning avideo ticket, AS 500 may learn which media files are appropriate—andperhaps even the order which they may be assembled, as indicated by agame play number—to create a video presentation associated with asession.

In summary, in some embodiments AS 500 (and/or another device) may (i)receive session result data associated with an executed session, and(ii) determine media files based on the session result data. In someembodiments, as a game play number may be associated with an outcomeindicated in session result data, an order in which media files may beassembled to create a video presentation may be determined as well.

Referring now to FIG. 11B, illustrated therein is a tabularrepresentation 1100B of another example embodiment of media filedatabase 525 (e.g., as it may be stored in a memory of AS 500 and/or amemory of another device). Tabular representation 1100B is referred toherein as media file record 1100B.

The media file record 1100B includes a number of example entries,including entries R1100-1 through R1100-9, each defining a media fileavailable for inclusion in a video presentation depicting outcomes for asession. Those skilled in the art will understand that the media filerecord 1100B may include any number of entries. The media file record1100B also defines fields for each of the entries or records. The fieldsspecify: (i) a game 1105B that indicates a game to which the media filescorrespond (the identifier may be in an alphanumeric or text form; theidentifier may be in machine and/or human readable form); (ii) a gametype file 1110B, which stores a media file comprising data indicating atype of game for which the outcomes of a current session weredetermined; (iii) a game brand file 1115B, which stores a media filecomprising data indicating a brand of the game (e.g., a logo of themanufacturer of the game and/or a logo of the title of the game) forwhich the outcomes of a current session were determined; (iv) a casinobrand file 1120B, which stores a media file comprising data indicating acasino at which the outcomes of a current session were determined (e.g.,the logo of the casino, an aerial shot of the casino, a drawing orpicture of the outside of the casino, etc.); (v) a payout 1125B, whichindicates a particular amount of a payout; (vi) a payout media file1130B, which stores a media file comprising data indicating the indiciacorresponding to the amount of the payout; and (vii) a duration 1135Bthat indicates a duration of a corresponding payout media file.

Media record 1100B is included herein to illustrate another embodimentof a media file database, one in which media files are selected based onpayout amounts instead of outcome identifiers. For example, AS 500 mayperform processes very similar to those described with respect to FIG.11A for creating a video presentation. However, rather than selectingoutcome media files based on outcomes and the order thereof determinedfor a session, AS 500 may instead select payout media files and put themtogether in a particular order to create a video presentation based onpayout data that is determined based on session result data for aparticular session. For example, as described in detail herein, in oneembodiment AS 500 may receive an indication of (i) a starting creditmeter balance for a session, (ii) a wager per game play, (iii) a numberof game plays comprising the session, and (iv) an ending credit meterbalance for the session. Based on this information, AS 500 may determinethe particular payouts, and the order thereof, to be depicted in a videopresentation created for the session. The AS 500 may then access record1100B and select the appropriate payout media files 1130B. In anotherembodiment, AS 500 may receive the information of the particular payoutsobtained for a session and, in some embodiments, the order thereof, andmay access record 1100B based on this information.

The fields 1105B through 1120B, as well as field 1135B, correspond tothe fields of the same name in FIG. 11A. Accordingly, the descriptionsthereof need not be repeated. Similarly, the description of additionaland/or different data that may be stored in record 1100A applies equallyto record 1100B and need not be repeated.

Referring to both FIGS. 11A and 11B, in accordance with some embodimentsa device (e.g., AS 500) may be operable to create a database of mediafiles for use in creating a video presentation. For example, oncecertain parameters (e.g., one or more of game type, game brand, casinobrand, wager per game play, number of players, a payout schedule to beused, etc.) are entered (e.g., by an operator of the device), the devicemay be operable to

(i) generate each possible outcome or payout combination (which step mayinclude determining the set of indicia comprising each outcome);

(ii) for each outcome:

animate the code depicting the outcome;

encode to a specific format desired; and

store the resulting media file to a database (e.g., the database of FIG.11A or FIG. 11B).

In some embodiments, the above process is performed in association witheach of the possible outcomes. In other embodiments, each possibleoutcome is determined once for each of a plurality of possible startingcredit meter balances.

In some embodiments, the device may further be operable to update amedia file database with the location of a particular file createdand/or the media file itself if the media file is stored in thedatabase. The device may also be further operable to create audio foreach video media file simultaneously with the process described above.In other embodiments, the device (or another device) may be operable tocreate appropriate audio for a video media file in a separate process.For example, there may be a smaller number of distinct audio filesrequired than there are video files (e.g., each winning outcome,although it depicts different indicia and corresponds to a differentpayout, may include the same audio file). In some embodiments, the audiois stored (e.g., multiplexed and/or interleaved) with a video file whilein other embodiments an audio file and video file are stored as separatefiles.

Once media files have been determined, a video presentation may becreated using the media files. Various processes for creating a videopresentation based on media files are described herein (e.g.,particularly with reference to FIGS. 17, 20 and 21A and 21B). Forexample, in some embodiments, a video presentation may comprise a seriesof media files (e.g., animations of slot machine reels spinning andaccompanying sounds) that a player may view (e.g., in succession orindividually). Thus, a player may remotely watch a video presentation ofa session, and learn of a plurality of outcomes comprising the sessionby watching recreations or renderings of the outcomes, though the actualgeneration of such outcomes may have occurred previously (e.g., in alegal jurisdiction, such as a casino).

Referring now to FIG. 12, illustrated therein is a tabularrepresentation 1200 of an example embodiment of a record of a sessionmedia file database 530 (e.g., as it may be stored in a memory of AS 500and/or a memory of another device). Tabular representation 1200 isreferred to herein as session media file record 1200. The session mediafile database 530 may be utilized, for example, to store the media filesselected (and, e.g., the order thereof) for a particular session. Forexample, as AS 500 accesses a record 1100A or 1100B to select the mediafiles for a video presentation to be created for a session, AS 500 maycreate a new record in a session media file database 530 for thesession. Then, as AS 500 selects files for the video presentation of thesession from the record 1100A or 1100B, it may populate the newlycreated record of the session media file database 530 to store anindication of the media files selected and the order in which thesemedia files are to be put together in the resulting video presentation.

The session media file record 1200 includes a number of example entries,including entries R1200-1 through R1200-9, each defining a media file tobe included in a video presentation for a current session. The term “acurrent session”, as the term is used with respect to FIG. 12, refers tothe session for which a video presentation is being created and forwhich media files are being selected. Those skilled in the art willunderstand that the session media file record 1200 may include anynumber of entries. The session media file record 1200 also definesfields for each of the entries or records. The fields specify: (i) asession identifier 1205 that uniquely identifies a session; (ii) a mediafile order indicator 1210 that indicates the order in which the mediafiles selected for the video presentation are to be put together in thevideo presentation; (iii) a media file 1215, which stores a media fileor an indication of the media file; and (iv) a media file description1220 that describes what is included in the corresponding media file.

As described herein, in some embodiments a video presentation mayinclude content in addition to video/audio representations of outcomes.For example, a video presentation may begin with an animated logo of agame and casino associated with a session based on which the videopresentation was created. Accordingly, a media file of the game brandmay begin the video presentation (as depicted in entry R1200-1 of recordR1200), followed by a media file of the casino logo (as depicted inentry R1200-2 of record R1200). The video presentation may then continueby presenting, in sequential order, a plurality of outcomes (as depictedin entries R1200-3 through R1200-5). In some embodiments, a message maybe included in the video presentation, in between the depiction ofrepresentative outcomes (as depicted in entry R1200-6). It should beunderstood that, although the media files of session S-01927 aredepicted as being ordered in sequence, in some embodiments two or moremedia files or the contents thereof may be presented simultaneously inone or more frames of a video presentation (as described above withreference to FIG. 11A). For example, the game and/or casino logo maypersist from frame to frame as different representative outcomes arepresented during the video presentation.

As described herein, some types of presentations may include a pluralityof (e.g., simulated) players. Accordingly, in some embodiments the mediafile description 1220 may include an indication of which of at least oneof a plurality of players are depicted in the media file (e.g., a mediafile may be described as “OUTCOMES FOR RED AND BLUE PLAYERS”).

Referring now to FIGS. 13A-13C, collectively, illustrated therein is atabular representation 1300 of an example embodiment of a DVD productionqueue database 535 (e.g., as it may be stored in a memory of AS 500and/or in the memory of another device). Tabular representation 1300 isreferred to herein as DVD production queue database 1300.

The DVD production queue database 1300 includes a number of examplerecords or entries, including records R1300-1 through R1300-3, eachdefining a DVD that has been placed in a production queue (e.g., aproduction queue of AS 500). Those skilled in the art will understandthat the DVD production queue database 1300 may include any number ofrecords or entries. The DVD production queue database 1300 also definesfields for each of the entries or records. The fields specify:

(i) an order number 1305 that stores a unique order number identifyingthe order in which the request for the DVD of the particular record wasreceived (e.g., a casino or other entity may place an order for 1,000DVDs and each of the DVDs may be associated with the same order number;in another embodiment, each DVD may be associated with a distinct andunique order number);

(ii) a customer identifier 1310 that stores an identifier of a customerwho ordered the DVD of the record (e.g., casino, GD manufacturer, playeror other entity);

(iii) a disc identifier 1315 that uniquely identifies a DVD of therecord;

(iv) a game brand 1320 that stores an indication of the game for whichthe outcomes to be represented in the video presentation to be recordedon the DVD of the record were determined;

(v) a casino 1325 that identifies the casino associated with theoutcomes to be represented in a video presentation to be recorded on theDVD of the record;

(vi) a denomination 1330 of the GD to be represented in a videopresentation to be recorded on the DVD of the record;

(vii) a wager per game play 1335 used in generating the outcomes to berepresented in a video presentation to be recorded on the DVD of therecord;

(viii) a payout schedule identifier 140 that identifies the payoutschedule (i.e., active payout combinations) utilized in determining theoutcomes to be represented in a video presentation to be recorded on theDVD of the record;

(ix) a number of game plays 1345 to be represented in the videopresentation to be recorded on the DVD of the record;

(x) a starting credit meter balance 1350 that indicates the value of thecredit meter balance prior to any outcomes being determined for thesession to be represented in the video presentation to be recorded onthe DVD of the record (which, in some embodiments, may be the price ofthe DVD);

(xi) an end credit meter balance 1355 that indicates the value of thecredit meter balance once the last of the outcomes comprising thesession to be represented in the video presentation to be recorded onthe DVD of the record has been generated (which, in some embodiments,may be the redemption value of the DVD);

(xii) a session identifier 1360 that uniquely identifies the session tobe represented in a video presentation to be recorded on the DVD of therecord (which session identifier may be used to access records of otherdatabases, such as a record of a session media file database (an exampleof which is described with respect to FIG. 12));

(xiii) an order submission time 1365 that indicates a date and/or timeat which the order for the DVD of the record was submitted (e.g.,received by the AS 500);

(xiv) a production start time 1370 that indicates a date and/or time atwhich production of the DVD was begun (in some embodiments, thebeginning of the production of the DVD may be considered to be the timeat which the video presentation to be recorded on the DVD is begun to bedetermined (e.g., by selecting appropriate media files to be included onthe DVD); in other embodiments this time may be considered to be thetime at which the recording of the video presentation onto the DVD isbegun, or another event);

(xv) a production step 1 time 1375 that indicates the date and/or timeat which a first step of a process to produce or create the DVD of therecord was begun (alternatively or additionally, the time at which thefirst step was completed may be stored);

(xvi) a production step n time 1380 that indicates the date and/or timeat which an n^(th) step of a produces to produce or create the DVD ofthe record was begun (alternatively or additionally, the time at whichthe n^(th) step was completed may be stored; it should be understoodthat the number of fields for recording the beginning time of each stepin a DVD production process is based on the number of steps included inthe process);

(xvii) a production completed time 1385 that indicates the date and/ortime at which the production of the DVD was completed (in someembodiments, the completion of production may be considered to be thevideo presentation being recorded onto the DVD; in other embodiments,the completion of production may be considered to be when the DVD isappropriately packaged and is ready for shipment, or another event);

(xviii) a shipped time 1390 that indicates a date and/or time at whichthe DVD of the record was shipped (e.g., to the customer indicated infield 1310).

The DVD production queue database 1300 may be utilized, for example, totrack the process of producing each DVD. For example, a new record maybe created in the DVD production queue database 1300 upon an order for aDVD being received. For example, an employee associated with AS 500 mayenter the information into the database upon receiving an order. Inanother embodiment, CS 305 or another device may be operable to writedata to the DVD production queue database 1300. A particular record maybe updated (e.g., based on the disc identifier and/or sessionidentifier) as the corresponding DVD moves through the productionprocess. Of course, additional and/or different information may bestored in the DVD production queue database 1300.

A DVD may be created using a combination of databases. Example processesfor using various databases to create a DVD and track the progressthereof are described in detail herein.

Referring now to FIG. 14, illustrated therein is a tabularrepresentation 1400 of a record of an example embodiment of an outcomesets database 540 (e.g., as it may be stored in a memory of AS 500and/or a memory of another device). The tabular representation 1400 isreferred to herein as outcome sets database record 1400. It should benoted that, in the embodiment depicted via FIG. 14, a record may becreated in an outcome sets database 540 for each desired combination ofthe following parameters and values thereof: (i) a game; (ii) a numberof game plays; and (iii) a wager per game play. Thus, for example, if acasino or other entity desires to sell, for a given game, (i) some DVDshaving 500 outcomes depicted at a wager of $1.00 per game play, (ii)some DVDs having 500 outcomes depicted at a wager of $0.50 per gameplay, (iii) some DVDs having 1,000 outcomes depicted at a wager of $1.00per game play, and (iv) some DVDs having 1,000 outcomes depicted at awager of $0.50 per game play, there may be four distinct records createdfor the game. Each record corresponds to a unique combination of: (i)game, (ii) number of game plays; and (iii) wager per game play. Ofcourse other parameters may be included in creating such combinations ofparameters, such as a particular payout schedule to be used, a number ofplayers, etc. Varying the number of parameters characterizing a recordwill affect the number of records that are appropriate for a given game.

The outcome sets database 1400 includes a number of example records orentries, including records R1400-1 through R1400-n, each defining aplurality of sets of outcomes corresponding to a particular end creditmeter balance for a particular combination of game, number of game playsand wager per game play. Those skilled in the art will understand thatthe outcome sets database 1400 may include any number of records orentries. The outcome sets database 1400 also defines fields for each ofthe entries or records. The fields specify: (i) a game identifier 1405that indicates (e.g., in alphanumeric form) a particular game to whichthe sets of outcomes correspond; (ii) a number of game plays 1410characterizing a current session (i.e., the session for which a set ofoutcomes is being determined); (iii) a wager per game play 1415 thatindicates the wager posted for each game play of the current session;(iv) a final credit meter balance 1420 that indicates the end creditmeter balance of a current session; (v) a first set of outcomes 1425that corresponds to a particular end credit meter balance; (vi) a secondset of outcomes 1430 that corresponds to a particular end credit meterbalance; and (vii) an n^(th) set of outcomes 1435 that corresponds to aparticular end credit meter balance. It should be understood that anynumber of sets of outcomes may be used.

The database 540 may be used, for example, to determine a set ofrepresentative outcomes to be included in a video presentation to berecorded onto a DVD. As described herein, in some embodiments, AS 500(or another device operable to create a video presentation to berecorded onto a DVD) may receive an indication of a plurality ofoutcomes comprising a session (i.e., session result data) that includesan indication of (i) the game for which the outcomes of the session weredetermined; (ii) the number of game plays comprising the session; (iii)the wager per game play; (iv) the end credit meter balance at thecompletion of the session. Based on such session result data, the AS 500may determine a set of representative outcomes to be included in a videopresentation to be recorded on a DVD, for indicating the session resultdata to the player in a player friendly format.

In one embodiment, selecting the set of representative outcomes may bebased on an end credit meter balance of the session. In such anembodiment, the outcome sets database illustrated via record 1400 may beused. For example, for each possible end credit meter balance of asession corresponding to a particular combination of a game, number ofgame plays and wager per game play, there may be associated severalpossible sets of outcomes. AS 500 may thus access the appropriate recordof the outcome sets database based on the combination of game, number ofgame plays and wager per game play indicated in the session result data.The AS 500 may then determine the appropriate sets of outcomes based onthe end credit meter balance included in the session result data.

In some embodiments, the AS 500 may then further select one of the setsof outcomes to include in a video presentation based on a predeterminedrule (e.g., randomly, in sequence such that each set of indicia sets iscycled through in an orderly basis, or based on another rule). In oneembodiment, each set of outcomes includes an indication of the indiciacomprising each outcome and the order in which the outcomes are to bepresented. In another embodiment, each set of outcomes includes anindication of the payouts to be represented in the video presentationand the order in which the payouts are to be presented in the videopresentation (each payout being presented by presenting a media filedepicting the appropriate set of indicia representing the payout).

In some embodiments, the AS 500 may, after selecting a set of outcomesfrom the plurality of sets of outcomes corresponding to a particular endcredit meter balance, determine the appropriate media file for eachoutcome of the set by accessing a media file database (e.g., media filedatabase 525). For example, AS 500 may access the media file database1100A of FIG. 11A if the outcome set includes a set of outcomeidentifiers, or the media file database 100B of FIG. 11B if the outcomeset includes a set of payout identifiers.

In some embodiments the media file is searched. If it does not yet existit is created. After creation, the media file is stored in a manner thatallows searching (e.g., a file and a pointer to the file in a database).In this manner, should the same outcome be needed in the future, thesystem does not need to create the media file yet again. In this manner,the database of prepared media files will grow over time.

It should be noted, with respect to each of fields 1425, 1430 and 1435,that although only a few outcomes are illustrated in each set, inpractice the number of outcomes may be equal to the number of game playscomprising the session (i.e., if the session comprises 500 game plays,each set of outcomes may comprise 500 outcomes).

It should further be noted, also with respect to each of fields 1425,1430 and 1435, that each set of outcomes corresponding to a particularend credit meter balance may be populated via a program designed todetermine an appropriate set of outcomes and corresponding payouts basedon the desired combination of parameters (e.g., such as game, number ofplayers, number of game plays and wager per game play). Such a programmay be run and the sets of outcomes determined for each possible endcredit meter balance prior to any DVD being created in accordance withembodiments of the present invention. In other embodiments, such aprogram may be run in order to determine one or more appropriate sets ofoutcomes based on the desired combination of parameters once sessionresult data indicating a value for each of the desired parameters isreceived.

Referring now to FIG. 15, illustrated therein is a tabularrepresentation 1500 of a probability database 620 (which may be storedin GD 600 or in another device). Tabular representation 1500 is referredto herein as probability database 1500. It should be noted that, in someembodiments, a plurality of probability databases may be stored and/orused. For example, a first probability database may be used for a firstgame and a second probability database may be used for a second game. Inanother example, a first probability database may be used when a GD isoperating in a conventional mode (e.g., a player is playing the GD toobtain and view outcomes one-by-one) and a second probability databasemay be used when a GD is operating in a “session outcome generationmode” (e.g., the GD is generating a plurality of outcomes to be storedon a DVD and sold to a player for remote viewing of the outcomes at asubsequent time). A first probability database may be different from asecond probability database, for example, by including (i) more, feweror different ranges of random numbers; (ii) a shorter or longer totalrange of available random numbers; and/or (iii) different outcomes. Theprobability database 1500 is thus an illustration of one exampleprobability database that may be stored for use in some embodiment.

Probability database 1500 includes a number of example records orentries, including records R1500-1 through R1500-18, each defining anoutcome available for a game on a gaming device. Those skilled in theart will understand that the probability database 1500 may include anynumber of entries. The probability database 1500 also defines fields foreach of the entries or records. The fields specify: (i) a random number(or range of random numbers) 1505 that may be generated by a randomnumber generator; and (ii) an outcome identifier 1510 that indicates theone or more indicia comprising the outcome that corresponds to therandom number or range of random numbers of a particular record.

A probability database 1500 may be utilized, for example, to determinewhat outcome corresponds to a random number generated by a random numbergenerator. For a three-reeled slot machine, for example, the outcomesmay comprise the three symbols to be displayed along a payline. Otherarrangements of probability databases are possible. For example, thebook “Winning At Slot Machines” by Jim Regan (Carol Publishing GroupEdition, 1997) illustrates examples of payout and probability tables andhow they may be derived. The entirety of this book is incorporated byreference herein for all purposes.

Referring now to FIG. 16, illustrated therein is a tabularrepresentation 1600 of a payout database 625 that may be stored in a GD600 or in another device. Tabular representation 1600 is referred to aspayout database 1600. It should be noted that, in some embodiments, aplurality of payout databases may be stored and/or used. For example, afirst payout database may be used for a first game and a second payoutdatabase may be used for a second game. In another example, a firstpayout database may be used when a GD is operating in a conventionalmode (e.g., a player is playing the GD to obtain and view outcomesone-by-one) and a second payout database may be used when a GD isoperating in a “session outcome generation mode” (e.g., the GD isgenerating a plurality of outcomes to be stored on a DVD and sold to aplayer for remote viewing of the outcomes at a subsequent time). A firstpayout database may be different from a second payout database, forexample, by including (i) different payouts for the same outcome; (ii)different payout combinations; and/or (iii) different indiciacorresponding to a payout. The payout database 1600 is thus anillustration of one example probability database that may be stored foruse in some embodiment.

Payout database 1600 includes a number of example records or entries,including records R1600-1 through R1600-18, each defining a payout for aparticular outcome or payout combination available for a game on agaming device. Those skilled in the art will understand that the payoutdatabase 1600 may include any number of entries. The payout database1600 also defines fields for each of the entries or records. The fieldsspecify: (i) an outcome identifier 1605 that uniquely identifies anoutcome; (ii) an outcome 1610 that corresponds to the outcome identifier(e.g., the set of indicia comprising the outcome); and (ii) a payoutthat corresponds to the outcome.

It should be noted that, in some embodiments, information illustrated asstored in a payout database and a probability database may be combinedand/or some information may be unnecessary and thus not stored. Forexample, in one embodiment, a probability database and payout databasemay be combined such that the resulting database stores (i) a randomnumber of range of random numbers field; (ii) a payout that correspondsto each random number or range of random numbers; and (iii) a payoutidentifier that uniquely identifies each payout. As described, in someembodiments a GD or SGD may generate a plurality of random numbers, eachrandom number being an outcome or result of a game play for a session.However, there may not be a need to determine a set of indiciacorresponding to each outcome or result. All that may be desired and/ornecessary is to determine the payout corresponding to each random numberso generated. Accordingly, a database such as described in thisparagraph may be appropriate for use in such embodiments. A GD or otherdevice may use such a database to determine the individual payouts for asession (based on the random numbers generated for the session) and/or asum of payouts for the session, without determining or being able todetermine a set of indicia that corresponds to any particular randomnumber. In some embodiments, as described, the individual payouts and/orsum of payouts determined for a session may be transmitted orcommunicated to another device, such as AS 310, for translation andstorage onto a DVD. A set of indicia may be determined by this otherdevice, for example, during a translation process that determines atleast one set of indicia based on the individual payouts and/or sum ofpayouts of the session.

5. Processes

Referring now to FIG. 17, illustrated therein is a flowchart of anexample process 1700 for determining representative outcomes to beincluded in a video presentation to be recorded onto a DVD. The processincludes a sub-process for selecting the media files to be assembledinto the video presentation, which in some embodiments may be a separateprocess. The process 1700 may be performed, for example, by AS 500. Ofcourse, as described herein, any process described herein may beperformed by any device or combination of devices that is practicableand desirable. Further, as also applies to all processes describedherein, the steps may be performed in an order different from thatillustrated and additional or different steps may be included.Similarly, some steps may be omitted or combined.

The process 1700 may begin, for example, upon receiving session resultdata and/or a DVD order based on which a DVD is to be created. Based onthe received session result data and/or order information, variousinformation is determined, for use in determining a set ofrepresentative outcomes to be represented in a video presentation to berecorded onto a DVD. The information may further be used to selectparticular media files (e.g., video and/or audio files) for use increating the video presentation.

In step 1705 a price for the set of outcomes (e.g., representativeoutcomes) to be included on the DVD is determined. In some embodiments,the price may comprise the initial credit meter balance for the session,to be represented in the video presentation. In some embodiments, thisprice is the price to be charged to a player (or other purchaser) forpurchasing the DVD.

The aggregate payout for the set of outcomes (and thus for the session)is determined in step 1710. The aggregate payout for the session is thesum of all payouts determined by a GD when generating the actual outcomefor the session. For example, if five actual outcomes were generated andthree of them corresponded to a payout of zero, while one correspondedto a payout of three (3) credits while the fifth corresponded to apayout of four (4) credits, the aggregate payout for the session isseven (7) credits. It should be understood that the aggregate payoutdetermined in step 1710 may be indicated in any format or denominationdesired (e.g., number of credits and the corresponding value of eachcredit, dollar value, etc.).

A desired profit margin for the DVD is determined in step 1715. In someembodiments, the desired profit margin may inherently be programmed intoa GD that creates the actual outcomes for the session, as part of thehouse advantage that a probability table used in determining the actualoutcomes is based on. In such embodiments, a separate determination ofthe desired profit margin in process 1700 may be unnecessary, as thismay inherently be included in the session result data (e.g., price,aggregate payout, wager per game play, etc.).

The number of representative outcomes to be included in the videopresentation (typically the number of actual outcomes determined by aGD, on which the session result data is based) is determined in step1720. For example, the session result data may include the number ofgame plays, and thus the number of outcomes, comprising the session.

The wager amount per game play is determined in step 1725. This may be,for example, an actual wager amount per game play, an average wageramount per game play for the number of game plays, etc. In someembodiments (e.g., embodiments in which the wager amount per game playdoes not vary from one game play to another in a given session), thewager amount per game play may be determined by dividing up the price ofthe set of outcomes (determined in step 1705) by the number of outcomesto be included (determined in step 1720). In other embodiments, thewager amount(s) may be explicitly included in the session result data.For example, the session result data may specify that the wager amountper game play is “$0.50” or, even more specifically, list each game playand the corresponding wager amount.

The game to which the outcomes correspond (the game for which a videopresentation is to be recorded onto the DVD) is determined in step 1730.Again, this information may be included in the session result data orDVD order.

Based on the above information, a set of representative outcomes isdetermined in step 1735. For example, a database may be accessed and theset of representative outcomes retrieved from an appropriate record ofthe database.

For example, in one embodiment the set of representative outcomes may bedetermined from an outcome sets database 540 (e.g., such as the onedepicted in FIG. 14). A particular record of the database may beaccessed based on the number of outcomes or game plays, and the wagerper game play. The appropriate plurality of sets of outcomes may bedetermined based on an ending session balance (which may be included inthe session result data or calculated based on the price, aggregatepayout, number of game plays and wager per game play information). Thenone of the sets of outcomes may be selected (e.g., randomly or based onanother rule). In some embodiments, a process of determining a set ofoutcomes or set of payouts based on session result information such asan ending credit balance may be a distinct process performed separatelyfrom the reminder of process 1700 (e.g., by the same device or adifferent device from the device performing other steps of process1700).

In another example, a program may generate a representative set ofoutcomes based on the parameters determined in steps 1705-1720. In yetanother example, the set of outcomes may be included in the sessionresult data (e.g., another device, such as CS 305 may have determinedthe representative outcomes and/or the actual outcomes determined by theGD may be used as the representative outcomes directly).

In one embodiment, determining the set of outcomes may includedetermining an order in which the outcomes are to be represented in avideo presentation (e.g., which may differ from an order in whichcorresponding actual outcomes were generated by a GD).

In one embodiment, determining the set of representative outcomes maycomprise determining a set of payouts (and, e.g., the payout identifiercorresponding to each payout and/or the order in which the payouts areto be presented in the video presentation).

Once the set of representative outcomes is determined in step 1735, theprocess 1700 continues to steps 1740 and 1745. It should be noted that,in some embodiments, the process 1700 may end at step 1735 and anotherprocess (e.g., performed by another device) may comprise steps 1740 and1745. For example, part of process 1700 may be to store the set ofrepresentative outcomes determined in step 1735 (e.g., in a record of adatabase, accessible by the unique session identifier, a unique discidentifier and/or an order identifier). For example, the outcomeidentifier (e.g., and/or payout identifier, as appropriate and desired)for each outcome determined in step 1735 may be stored in such adatabase. This database may be subsequently accessed for purposes ofperforming steps 1740 and 1745 or similar steps.

In step 1740, media files are determined and/or selected based on theset of representative outcomes determined in step 1735. For example, amedia file database 525 (e.g., such as the one illustrated in FIG. 11Aor the one illustrated in FIG. 11B) may be accessed. For example, aparticular record may be selected from the database based on the game(in some embodiments the record may be selected based on the game andcasino, if, for the same game, there are different media files storedfor different casinos). Then the appropriate media files may be selectedbased on the outcome identifiers of the outcomes determined in step1735. Determining the media files may include determining media files inaddition to media files storing an image or animation of the outcomes.For example, a media file storing an image or animation of a payoutschedule, a congratulatory message, an advertisement, a credit meterbalance and/or other material may also be selected and assembled intothe video presentation. Of course, determining media files may includeselecting audio data files as well as video or image files and/orselecting files which later drive a software program.

In step 1745, the media files determined in step 1745 are assembled intoa video presentation. A particular process for assembling media filesinto a video presentation is described with reference to FIGS. 22A and22B. For example, the media files may be assembled into an order basedon an order in which the outcomes are to be presented.

Referring now to FIG. 18, illustrated therein is a flowchart of anexample process 1800 for determining a set of media files based on anindication of a set of desired payouts (or a set of desired outcomes),in accordance with some embodiments. The process 1800 may be utilized,for example, in embodiments in which AS 310 (or another device operableto determine media files to be included in a video presentation)receives a plurality of outcome identifiers and/or a plurality of payoutidentifiers and determines the media files based on these identifiers.For example, unlike the embodiment described with respect to FIG. 17, inwhich general data defining a session is received and representativeoutcomes are determined based on this data, in the embodiment of process1800 the identifiers of the actual outcomes may be received (or theidentifiers of the payouts corresponding to the actual identifiers) fromCS 305 or another device, thus requiring less processing on the part ofAS 310. The AS 310 may simply select the appropriate media files basedon the received identifiers. Of course, the embodiment of process 1800may require substantially more data to be transmitted from CS 305 to AS310 in the embodiment of process 1800 than in the embodiment of process1700. For example, in process 1700, it may be sufficient for CS 305 totransmit to AS 310 the following information regarding a particularsession: (i) a price of the session, (ii) an ending credit meter balanceof the session, (iii) an indication of the payout schedule used for thesession, and (iv) an indication of the ending credit meter balance forthe session. The AS 310 may then determine a plurality of representativeoutcomes based on this information. In the embodiment of process 1800,however, more information may be transmitted; the outcome identifierand/or payout identifier for each game play (which may be a substantialnumber of identifiers, as a session may comprise, for example, 500 or1,000 outcomes) may be transmitted.

In step 1805, a plurality of identifiers, each identifier identifying anoutcome and/or payout of a session, is received. For example, theidentifiers may be received from CS 305. In one embodiment, theidentifiers may be stored in a database and subsequently retrieved. Inone embodiment, the identifiers of payouts may comprise the values ofthe payouts. For example, a record (e.g., such as the one illustrated inFIG. 26 described below) may be used to store the plurality of payoutvalues for a session. In one embodiment, the information received instep 1805 may include an indication of an order in which the outcomesand/or payouts are to be represented in a video presentation for thesession. In one embodiment, for example, some or all of the informationstored in a record of a session database 425 (e.g., such as the record700A of FIG. 7A) may be received by AS 310 as part of step 1805.

In step 1810, the game, for which the outcomes and/or payouts of step1805 were received, is determined. This information may be used toaccess an appropriate record of a media file database. For example, asdescribed with respect to FIG. 11A and FIG. 11B, a distinct set of mediafiles may be stored for each available game. In one embodiment, process1800 may further comprise receiving an indication of a casino to berepresented in the video presentation (e.g., a casino in which theactual outcomes of the session were generated, a casino that placed theorder for the DVD and/or the casino in which the DVD is to be sold). Asdescribed with reference to FIG. 11A and FIG. 11B, in some embodimentsmedia files of outcomes for a particular game may be further customizedto reflect a particular casino. In such embodiments, an appropriaterecord of a media file database may be accessed based on a desiredcombination of game and casino.

In step 1815, the media files for the video presentation to be createdare determined based on (i) the outcome identifiers and/or payoutidentifiers received in step 1805 and (ii) the game determined in step1810. For example, a media file database such as the one depicted inFIG. 11A may be accessed and the appropriate media files selected basedon the outcome identifiers.

In step 1820, an indication of the media files (or file) determined instep 1815 (and, in some embodiments, the media files themselves orcopies thereof) may be stored in association with a session identifieror other unique identifier associated with the session (e.g., a discidentifier identifying the DVD on which the media files are to beincluded as part of a video presentation to be recorded onto the DVD).Storing the media files may comprise, for example, creating or opening apreviously created record of the session media file database 530. Forexample, a record such as the record 1200 (FIG. 12) of such a databasemay be created (e.g., during the execution of process 1800) andpopulated with the media files (or indications or copies thereof)determined in step 1815, in an order in which the media files are to beassembled into the video presentation. It should be understood that astep similar to step 1820 may be performed in process 1700 or any otherprocess described herein that involves the creation of a videopresentation.

Referring now to FIG. 19, illustrated therein is a flowchart of anexample process 1900 for creating a DVD. The process 1900 is meant as anoverview of the process of creating a DVD and does not include manydetailed steps or sub-routines that may be involved in such a process.FIG. 20 and FIGS. 21A and 21B illustrate more detailed example processesfor creating a DVD.

In step 1905, the desired parameters for a DVD to be created aredetermined. For example, an order for a DVD and/or session result datamay be received. In one embodiment, some or all of the information in asession database 425 (such as the one embodied in the example record700A of FIG. 7A) may be communicated in step 1905 as an indication ofthe parameters of the DVD to be created.

Examples of parameters that may be determined in step 1905 include,without limitation, (i) a price of the DVD (which may, in someembodiments, be the starting credit meter balance of the session basedon which the DVD is to be created; (ii) a game; (ii) a gaming device;(iii) a casino; (iv) a payout schedule; (v) a strategy to be employed inmaking decisions on behalf of a player; (vi) an ending credit meterbalance; (vii) a number of game plays or outcomes to be represented;(viii) a wager per game play; (ix) outcomes to be represented; (x) anorder of outcomes to be represented; (xi) advertisements, promotional orother material to be included in the video presentation to be includedon the DVD; (xii) audio to be included on the DVD; (xiii) a languagepreference in which the material in the DVD is to be presented; (xiv) anumber of players to be represented; and/or (xv) one or more payouts tobe represented on the DVD. It should be understood that some of theabove items may be redundant with other items. It should further beunderstood that not all of the above-listed parameters are required tobe known in order to create a DVD.

It should still further be understood that, in some embodiments, some ofthe parameters (and values thereof) may be determined by a first device(e.g., CS 305) and transmitted to a second device (e.g., AS 310)performing step 1905, while other parameters (and values thereof) may bedetermined directly by the second device. The second device maydetermine such additional parameters (and values thereof), for example,based on information received from the first device and/or based on aprogram or instructions stored in a memory of the second device.

In other embodiments, all of the parameters (and values thereof) may bedetermined by the first device and transmitted to the second device, thesecond device having minimal processing capabilities and merely servingto assemble the video presentation and record it onto a DVD.

In step 1910, the DVD is queued for production. For example, a recordmay be created in a DVD production queue database 535 (an exampleembodiment of which is illustrated in DVD production queue database 1300of FIGS. 13A-13C). For example, a unique disc identifier may bedetermined and used to create a new record. At least some of theparameters determined in step 1905 (and values thereof) may be stored inthe record. The disc identifier may be placed in a DVD production queue.A device for producing the DVDs (or at least the device performing afirst step in the production process), such as AS 500, may select theDVDs to be created on a first-come-first-serve basis (e.g., based on theorder submission time, based on the disc identifier, etc.).

In step 1915 it is determined whether the DVD has been created. Forexample, it may be determined whether a record for the DVD in a DVDproduction queue database indicates that the production process for theDVD has been completed. In a more particular example, the DVD productionqueue database 1300 may be accessed to determine whether there is anentry in the production completed time field 1385.

If it is determined that the DVD has been created, the DVD is madeavailable for purchase in step 1920. For example, the DVD may bepackaged in a shipment of a plurality of DVDs intended for a particulardestination (e.g., a casino identified in customer identifier field 1310of the DVD production queue database 1300) and shipped to thedestination. Otherwise, the process 1915 loops until it is determinedthat the DVD has been created.

In some embodiments, session result data may be generated and stored inadvance of the receipt of a request to produce a game disc. For example,session result data may be “warehoused” (e.g., generated and then storeden masse), such that at a later point, a disc may be created using thehistoric results. In other embodiments, a device may be configured togenerate game play results for a session on demand (e.g., upon receivinga signal from another device). In still further embodiments, a devicemay be configured to continuously produce game play results (e.g., thedevice produces one result every second, continually), which game playresults may be utilized when game play results are desired pursuant tothe creation of a video presentation for a DVD (e.g., when a disccomprising 500 outcomes is desired, the next 500 seconds worth of gameplay results generated by the device are monitored, accessed, recordedand/or otherwise utilized to create the disc).

Such a device may then itself produce a disc, or communicate with one ormore devices configured to product such a disc. For example, a memory ofa device may store a program for determining one or more media filesbased on session result data, as described. Thus, a number of mediafiles (e.g., audio and/or video clips or recordings of various slotmachine animations) may be determined in association with a disc. Asdescribed, in one embodiment, a device that generates game play resultsmay itself be configured to produce a video presentation and/or DVDhaving the video presentation recorded therein. For example, the devicemay comprise a program for determining which media files to encode on aDVD, as well as hardware for storing such files on a DVD and formattingthe DVD in a manner such that the DVD may be viewable by conventionaldevices (e.g., the device comprises hardware and software that allowsfor the production of DVDs). In other embodiments, session result dataand/or media files may be accessed by or transmitted to one or moreseparate devices (e.g., via a communications network) from the devicethat generates the game play results, such that the one or more separatedevices may then produce the video presentations and/or discs. Forexample, in one embodiment, a central computer may receive blocks ofgame play results from a plurality of devices (e.g., GDs and/or MGDs).For example, each such device my produce a plurality of game playresults, and transmit the results (perhaps along with a sessionidentifier) to the central computer (e.g., CS 305 and/or AS 310). Thecentral computer may comprise a program for accessing appropriate mediafiles based on the game play results and encoding them onto a DVD, aswell as hardware for transferring such files to a DVD (e.g., an opticallaser, etc.). Thus, one or more devices of such an automated facilitymay produce en masse discs according to various parameters, as describedherein.

In one embodiment, a secure facility may comprise one or more GDs forproducing game play results (e.g., MGDs that generate game play resultsin an automated fashion, with little or no human involvement).Additionally, such a facility may comprise various hardware and softwarefor producing DVDs based on the results generated by the GDs. Forexample, an “assembly line” of computerized and/or mechanized devicesmay be configured to (i) store appropriate media content on DVDs basedon game play results generated by the GDs, (ii) label such DVDs, (iii)package such DVDs (e.g., including adding barcodes, graphics, etc.)and/or (iv) shrink-wrap such packaging. Thus, such a facility maycomprise a variety of devices, one or more of which may communicate withone or more databases for determining necessary information forproducing such DVDs. For example, each DVD may be unique (e.g., the gameplay results thereof may be based on a session generated for thatparticular DVD), and therefore when producing each DVD, it may benecessary for various devices to communicate with one or more GDs (orotherwise obtain data generated by one or more GDs) and/or databases soas to determine appropriate content for the DVD. For example, anassembly unit may comprise a computer system in communication with amechanized or robotic arm that accesses physical media (e.g., lifts a“blank” DVD from a spindle of DVDs and places it into an area in whichthe DVD may subsequently be written to by an optical device). Thecomputer system may also be configured to instruct an optical device toencode the DVD with various content (e.g., indications of game playresults, a menu interface, etc.). The computer system itself may or maynot generate the game play results that are used to determine thecontent for the DVD. Accordingly, the assembly unit (e.g., the computersystem in communication with the mechanized hardware, optical device,etc.) may communicate with one or more devices and/or databases thatstore session results and/or media files for creating a videopresentation to be recorded onto a DVD.

In one embodiment, because numerous game play results may be generatedin a rapid or substantially instantaneous manner, game play results maybe generated as required for the production of a particular DVD (e.g.,as each DVD becomes ready for content, a GD is instructed to generategame play results). In other embodiments, game play results and/orassociated media files may be stored in a database, and then accessed asneeded.

In this manner, an assembly unit may produce a DVD storing indicationsof game play results in association with a particular session. Forexample, the DVD may be encoded with audio and/or video files depictingan animated slot machine producing various arrays of symbols, a creditmeter balance adjusting after each game play, etc. The DVD may furtherbe encoded electronically with a session identifier and/or other sessioninformation, a player identifier, and/or a code (e.g., an activationcode, a disc identifier, etc.), etc., such that when the DVD is insertedinto an appropriate reader device, such information may be accessed.Thus, in some embodiments, a plurality of DVDs may be manufactured, eachDVD comprising indications of unique session results.

In some embodiments, a facility for producing DVDs may further beconfigured to uniquely mark the packaging or labeling of such DVDs withone or more identifiers or codes. For example, a session identifier,player identifier, and/or activation code may be uniquely marked on thepackaging or labeling of a DVD, such that the code or identifier may beused to facilitate various steps described herein with respect to thesale, activation and redemption of such DVDs. Thus, in one example,after a DVD has been uniquely encoded with content by a first assemblyunit, the DVD may then be transferred to one or more second assemblyunits that may assist in the labeling and/or packaging of the DVD. Forexample, a second assembly unit may comprise a computer system incommunication with various hardware for applying graphics or otherlabeling to the top side of a DVD (e.g., a pressing unit appliespermanent color or grayscale images to the top side of the DVD). Such aunit may then communicate with one or more databases, such that one ormore identifiers associated with the DVD may then be determined (e.g., a“Disc Activation Number”). In one embodiment, a master computer systemmay keep track of each DVD's position within a series of assembly units,such that when a DVD reaches a second assembly unit, the unit may beinstructed to label the DVD with one or more identifiers. In anotherexample, the unit may determine an identifier by reading the DVD (e.g.,if the DVD was previously encoded with an identifier). In either case,the identifier may then be marked upon the DVD. In some embodiments, theidentifier may be machine-readable (e.g., a barcode is labeled upon thetop of the DVD). Alternately or additionally, a human-readableidentifier may be labeled upon the DVD (e.g., a numeric code isimprinted). In some embodiments, the labeled and encoded DVD may then betransported to one or more further assembly units. For example, yetanother assembly unit may be responsible for inserting the DVD into ajewel case, and/or for shrink-wrapping a jewel case, etc. Otherprocesses such as printing packaging materials (e.g., paper inserts orother paper materials that accompany jewel cases) may or may not takeplace in such a facility. For example, in one embodiment, a separatepress may receive instructions for imprinting a paper cover to beinserted into a jewel case with graphics and a unique identifier (e.g.,associated with a particular DVD). The paper cover may then later bemerged and/or otherwise incorporated into such an assembly process(e.g., the cover is matched to a jewel case containing the appropriateDVD).

It should be noted that various efforts may be made to ensure that theproduction of video presentations and/or DVDs on which such videopresentations are recorded in such an automated facility occurs withouttampering. For example, such devices and/or various components thereofmay be equipped with devices that indicate whether physical tamperinghas occurred (e.g., the casing of a device for generating game playresults comprises a tamper-evident seal). In other embodiments, acentral computer or server may authenticate or verify that the softwareof a device has not been tampered with, via a checksum or one or moreother such authentication procedures known in the art.

Further, gaming regulators may require various steps, for example, toprove that when creating DVDs, operators of a system may notpurposefully create “losing” video presentations and/or DVDs (i.e., onesthat correspond to a redemption value of zero) by selecting losingoutcomes, or manipulate the random nature of game play result generationin any fashion (e.g., physical or electronic tampering, which may bemonitored by a third party, would be evident). In some embodiments, itmay be desirable for a system to ensure that all of the game playresults generated are used in the creation of a video presentation (suchthat operators may not “pick and choose” which game play results toincorporate) or that the aggregate payout for the actual outcomesgenerated equals the aggregate payout for the representative outcomescomprising a video presentation. For example, the system mayauthenticate that if 100,000 game play results have been generated byone or more GDs (e.g., during a period of time, since the inception ofthe device, etc.), all 100,000 of such game play results have beenincorporated into the production of one or more DVDs. In a more specificexample, an electronic record may be kept of all the (uniquelyidentified) game play results generated by all GDs pursuant to theexecution of sessions, as well as all the game play results used torender videos of one or more DVDs (e.g., such that an auditor may checkthe results of the DVDs against the generated results).

In further embodiments, to help ensure fairness of production of DVDs,an operator of a system producing DVDs and/or video presentationstherefore may certify a payback percentage for an aggregate number ofDVDs (e.g., DVDs are produced in a manner such that for every 1,000 DVDsmade, the 1,000 DVDs will on average pay out a certain sum tocustomers). It should be appreciated that manners of auditing suchclaims are well known in the art (e.g., much as how a slot machinepayback percentage is audited).

In alternate embodiments, a system of the present invention may beconfigured similar to a system for producing “instant-win” or“scratch-off” lottery tickets, in that for every set of DVDs produced(e.g., every group of 500), it may be predetermined that certain DVDswill yield certain final credit meter balances or credit meter balanceswithin a certain range (e.g., in the batch of 500, there will be one DVDwith a final credit meter balance of 12,783 credits, four DVDs withfinal credit meter balance of 476, and so on). Thus, a final sessionbalance associated with each of a set of DVDs may be determinedsimilarly to a roll of instant-win lottery tickets (e.g., according to apredetermined matrix). As with a roll of instant-win lottery tickets, itmay be advantageous to distribute “winning” DVDs in a manner such that aseries of DVDs produced and sold in sequence (e.g., DVDs characterizedconsecutive numeric identification codes) do not result in almost alllosses. For example, a common game structure used in instant-win lotterytickets is known as “guaranteed low end prize structure” or GLEPS. Inthis structure, tickets are provided to the ticket-selling agents innumbered “books,” with each book containing a predetermined number oftickets. Each book of GLEPS game tickets contains a predetermined numberof low end, or small award, winning tickets. For example, small awardwinners may include awards up to, and including, ten dollars. Inaddition, ticket books may also contain additional winning tickets thathave larger prize values and are not part of the GLEPS structure. Theticket books are arranged in “pools” and these larger-amount tickets aredistributed over the ticket book pools in a truly random manner and aremuch less numerous than the GLEPS winning tickets. Thus, in someembodiments, DVDs may be produced in a similar manner (e.g., a matrix offinal contract/session balances may be associated with a pool of DVDs ina non-random manner, but the final credit/session balances may bedistributed to serially identified DVDs within the pool in at least apartially random manner).

Referring now to FIG. 20, illustrated therein is a flowchart of anexample process 2000 for creating a DVD. The process 2000 is describedwith particular reference to the embodiment of the DVD production queuedatabase 535 illustrated in FIGS. 13A-13C.

In step 2005, an order for a DVD is received. For example, an order froma casino for a plurality of DVDs may be received electronically and/orvia paper or other tangible medium. For example, a casino or othercustomer may transmit session result data for a plurality of sessions,thus ordering a DVD corresponding to each of the sessions. In someembodiments, an order may specify that a plurality of DVDs be createdbased on session result data for a particular session. In one example,the session result data of an order may be transmitted to AS 310electronically or be called in by a casino representative. In anotherexample, a document corresponding to one or more of the sessions may bereceived. For example, as described herein, in some embodiments one ormore session results tickets may be printed by a GD for a sessionexecuted by the GD. In one embodiment, step 2005 may include receivingthe session results tickets (or copies thereof) for each sessionincluded in the order. In some embodiments, each session may be receivedas a separate order.

In step 2010 a template is determined for the final DVD. As would beunderstood by one of ordinary skill in the art of producing DVDs, atemplate for a DVD may include an indication of information to beincluded in the DVD and may include items that are constant across abatch of DVDs. A template may further include programming commands(pause here, skip to there if this button is pushed, etc.) formanipulating the assets (i.e., content) of the DVD. In some embodiments,the same template may be used for all DVDs of the same game, casino,number of game plays and wager per game play. Thus, there may be aplurality of templates stored in a memory (e.g., a memory of AS 500) andstep 2010 may comprise selecting the appropriate template for use, basedon the session result information determined in step 2005. A particulartemplate may include, for example, an opening menu design, buttons,graphics, and advertising material. In some embodiments, some of thedata in a template may be variable (e.g., a first advertisement may beselected for inclusion in an advertising portion of a first DVD while asecond advertisement may be selected for inclusion in an advertisingportion of a second DVD).

In step 2015, a record for the DVD of the order is created in a database(e.g., DVD production queue database 1300). A record in the DVDproduction queue database 1300 may be created based on the receipt ofthe order. For example, a unique order number may be determined (e.g.,the order number may be received as part of the order or assigned to theorder upon the order being received) and stored in the newly createdrecord. The customer identifier for the order may also be recorded. Adisc identifier may be determined and stored as well. Additionalinformation regarding parameters of the DVD to be created may also bedetermined from the session result information of the order and storedin the record (e.g., game brand, casino, denomination, wager per gameplay, payout schedule, number of game plays, starting credit meterbalance, end credit meter balance, session identifier). The ordersubmission time (e.g., the time at which the order was received) mayalso be stored.

In step 2020, the DVD is created via a production process that maycomprise one or more steps. The steps may comprise, for example, (i)creating a video presentation to be recorded onto the DVD, (ii)recording the video presentation onto the DVD, (iii) packaging the DVD,and (iv) readying the DVD for shipment to the customer who ordered theDVD. Process 2100, described in detail with respect to FIGS. 21A-21B, isone example process for how a DVD may be created. In some embodiments,as a DVD proceeds through a production process comprising several steps,the appropriate record of the DVD production queue database 1300 isupdated upon the completion of each step, to track the progress of theDVD creation.

In step 2025 it is determined that the DVD has been successfully createdand the order is marked as ready for shipment. For example, productioncompleted time field 1385 may be updated to reflect the time at whichthe production process was completed, thus marking the DVD (or record ofthe DVD) to reflect that the DVD is ready for shipment.

Referring now to FIGS. 21A-21B, illustrated therein is a flowchart of anexample process 2100 for creating a DVD. The process 2100 may, in someembodiments, comprise an example of step 2020 of process 2000.

In step 2105, a set of representative and/or actual outcomes to beincluded in a video presentation are determined. For example, a processsimilar to that described with respect to FIG. 17 or a process similarto that described with respect to FIG. 18 may be utilized. In oneexample, representative outcomes may be determined based on sessionresult data received or identifiers of the representative outcomes maybe received.

In step 2110, at least one media file is determined for each of theoutcomes determined in step 2105. Determining a media file may comprise,for example, generating a new media file or retrieving a previouslycreated media file from a media file database or other memory structure.

In some embodiments, step 2110 may further comprise determining (e.g.,generating or retrieving) any other appropriate media files. Forexample, one or more media files comprising a graphic depicting one ormore of a meter of number of game plays remaining, a credit meterbalance and/or a payout schedule may be determined.

Step 2110 may comprise animating the media files. Animation of the mediafiles may comprise, for example, creating a sequence of frames which,when viewed together in rapid succession, simulate motion. Such asequence may comprise, for example, creating the frames pixel by pixel,copying the frames from a database, or any method on a continuum betweenthese two processes.

In step 2115, graphics are overlaid onto the media files depicting theoutcomes determined in step 2105, as appropriate. For example, a graphicof a credit meter balance or a meter depicting a number of spinsremaining may be overlaid onto particular portions of each frame of amedia file.

In some embodiments, step 2115 may further comprise determining an orderor other layout of the media files. For example, it may be determinedwhich frame or portion of a frame a particular graphic is to be overlaidon. In another example, an order in which the representative outcomesare to be determined (and thus an order in which the media filesdepicting the representative outcomes are to be output in the videopresentation) may be determined.

In step 2120, media preparation (e.g., such as MPEG compression) isperformed on the media files. In one example, MPEG compression isperformed on animation (e.g., media files that have been animated). Ofcourse, if the media files are to be stored in a format other than MPEG,another procedure may be performed on the media files to convert them tothe appropriate format. For example, another compression algorithm otherthan MPEG compression may be performed.

In step 2125, an audio track is created for the DVD. In some embodiments(e.g., embodiments in which a media file includes both video and audiodata), this step may be unnecessary. For example, the creation of theaudio track may be performed synchronously with the determination of themedia files or video files. In some embodiments, creating an audio trackcomprises selecting the appropriate audio media files and assemblingthem into an appropriate order based on the planned video content forthe video presentation.

In step 2130, the assets for the DVD (i.e. content to be included in theDVD, including video and audio content) are combined as specified in aDVD template being used to create the DVD. In some embodiments, process2100 may include a step of selecting the appropriate DVD template (someexamples of which were described with reference to step 2010 of FIG.20). The assets for the DVD may comprise, for example, the media filesand the audio track previously determined. The assets may also includeany still pictures, subtitles, or other content to be included on theDVD. For example, the template may say:

Opening Menu

-   -   create one button pointing to program point 10    -   play background music audio Z until button selected    -   pause

Point 10

-   -   play video Y

Step 2130 may comprise modifying the template for a specific DVD byinserting particular files into the template. For example, the abovetemplate may be modified by inserting “disc123/slotsvideo/video.mpg” forthe variable Y, and “disc123/menumusic/music.audio” for variable Z.

In step 2135, a DVD disc image is determined for the DVD. As would beunderstood by one of ordinary skill in the art of DVD production, a DVDdisc image is the logical structure for the DVD or directory structurewith the files in the proper LOGICAL location. Typically, a directorystructure comprises a top level directory which includes menu files, avideo directory and an audio directory. The video directory has a filefor each chapter, etc. However, the data on the disc itself may bephysically spread out over various physical locations on the disc (apractice referred to as fragmentation). Step 2135 may comprise, forexample, copying the media files determined in process 1200 into thecorrect logical structure.

In step 2140, an ISO (International Standards Organization) image (orbit-by-bit structure) is determined for the DVD, based on the standardbeing used. As would be understood by one of ordinary skill in the artof DVD production, an ISO image defines the actual layout of theindividual bytes of the files. Files may be interlaced (e.g., 100 bytesof video may be followed by 10 bytes of audio so a laser reading thedisc can play them together) and consecutive files may be physicallyconsecutive in the ISO disc image (unlike the DVD disc image). It shouldbe noted that step 2135 may be performed by a first program and step2140 may be performed by a second program, as is true for all steps ofprocesses described herein.

In step 2145, the DVD ISO image is recorded onto the DVD. Recording theISO image may comprise transferring the information onto a DVD. Forexample, in one embodiment recording a DVD may comprise stamping theDVD. In another embodiment, recording information onto a DVD ortransferring information onto a DVD may comprise burning the informationonto the DVD. For example, DVD-R or DVD+R burners may use relativelyhigh-powered lasers to darken inks inside a recordable DVD media tosimulate the pits of traditional mass-produced DVDs. Examples of suchtechnologies are readily available, such as DVD recorders from Plextor™or Panasonic™. In some of these embodiments, the DVD recording devicemay have multiple recording devices and a robotic mechanism for discmovement into and out of the drives. Examples of this technology includeRimage's Protoge Plus™, or Microtech's™ product lines.

In step 2150 a label is printed for the DVD. This may involve, forexample, determining a graphics image and printing it onto the label orDVD itself. The label may further include unique information such as aunique disc identifier or the session identifier. In some embodiments,the label may include an indication of the game and/or casinorepresented in the video presentation of the DVD.

In step 2155 the DVD is inserted into packaging. The DVD may be packagedsuch that tampering with the DVD (e.g., unauthorized opening of the DVD)is visible or otherwise easily discernable. Further, the DVD may bepackaged in anti-tampering material. Step 2155 (or another step ofprocess 2100) may further include storing an indication (e.g., in a DVDproduction queue database 535) that the DVD has been completed and isready for shipment. The time and/or date on which the production of theDVD was completed may also be stored. The DVD may then be transported toan appropriate destination (e.g., shipped along with many other DVDscreated in a similar manner to a casino that ordered the DVDs).

Referring now to FIG. 22, illustrated therein is a process 2200 forfacilitating the purchase of a DVD or a session in another remotelyviewable form. The process 2200 may be performed, for example, by POS320.

In step 2205, a request to purchase a DVD is received. For example, inone embodiment a player may select, from a display, a DVD that hasrecorded thereon a video presentation based on outcomes previouslygenerated by a GD. Alternatively, the player may request that the casinoattendant provide a DVD from behind a casino counter. The player mayrequest to purchase the selected DVD. Step 2205 may comprise, forexample, receiving from a casino attendant into POS 320 an indicationthat a new transaction for the purchase of such a DVD is to beinitiated. In another embodiment, step 2205 may comprise receiving arequest that a DVD be generated on behalf of the player. In this latterembodiment, the request may include an indication of parameters (andvalues thereof) defining a session based on which a video presentationis to be created and recorded onto the DVD. For example, a player mayspecify a game, wager amount per game play, number of game plays, numberof depicted players, and price for the session and resultant DVD.

In step 2210, a unique identifier of the DVD is determined. For example,a unique disc identifier on the packaging of a DVD (or, in someembodiments, on the DVD itself) may be entered via a bar code scanner orkeyboard. In embodiments in which the request for the DVD comprises arequest that a DVD be generated on behalf of a player, step 2210 maycomprise determining or assigning a unique identifier for the DVD to becreated. For example, a unique DVD identifier may be generated based ona program or algorithm or a previously generated but as yet unassignedDVD identifier may be retrieved from a database of available DVDidentifiers. In one embodiment, step 2210 may comprise determining asession identifier of a session associated with the DVD previouslycreated or the DVD to be created.

In step 2215, it is determined whether the DVD is available forpurchase. For example, a database such as available DVDs database 1000of FIG. 10 may be accessed and it may be determined whether the statusof the DVD is set to “available,” or other information associated withthe DVD may be retrieved, based on the unique identifier determined instep 2210, that allows a determination of whether the DVD is availablefor purchase. In one embodiment, POS 320 accesses such information anddetermines the availability of the DVD for purchase. In otherembodiments, POS 320 transmits an indication of the unique identifier toanother device (e.g., CS 305), which determines the availability of theDVD for purchase and transmits an indication of the availability to POS320. In embodiments in which the request to purchase a DVD is a requestfor a DVD to be created, step 2215 may comprise determining whether asession as defined in the request of step 2205 may be created (e.g.,whether the requested combination of parameters and values thereof areapproved or approvable).

If the DVD is not available for purchase, a message indicating theunavailability of the DVD for purchase is output in step 2225. Forexample, such a message may be output to a casino attendant (who maycommunicate the message to the player requesting to purchase the DVD)and/or directly to the player requesting to purchase the DVD. Otherwise,the process 2200 continues to step 2220.

In step 2220, an activation code is received. The activation code maycomprise, for example, a code provided to a player upon a legitimatepurchase of a DVD, to be used by the player as subsequent proof of thepurchase and/or to activate a video presentation recorded on the DVD. Insome embodiments, the activation code may simply comprise a uniquetransaction identifier generated or otherwise determined by POS 320. Inother embodiments, an activation code may be distinct from a transactionidentifier. In some embodiments, a unique activation code may begenerated at the time of a purchase of a DVD (e.g., using an algorithmcreated for this purpose). In other embodiments, an activation code maybe selected from a list of previously generated and available activationcodes. In some embodiments, an activation code may be encrypted. In someembodiments, the activation code associated with the DVD at the time ofpurchase of the DVD may be stored in a record of a database associatedwith the DVD (e.g., in association with the disc identifier and/or otherunique identifier already associated with the DVD).

It should be noted that, in some embodiments, an activation code may bedetermined and associated with a particular DVD during the manufacturingprocess.

In step 2230, an indication of payment for the DVD is received. Forexample, an operator of POS 320 may indicate an amount and form ofpayment received for the DVD, as is known in the art of POS operations.In some embodiments, step 2230 may comprise first retrieving the priceof the DVD (e.g., from a database, such as available DVDs database 1000,or by scanning or otherwise determining a price indicated on the DVD orpackaging thereof).

In step 2235, a receipt for the DVD is output. Some examples of such areceipts are illustrated in FIGS. 23-26 (described in detail below). Forexample, POS 320 may cause a receipt to be printed. In some embodiments,the receipt for the DVD may be e-mailed to the player or provided to theplayer in another electronic form. In some embodiments, the activationcode may be included on the receipt. A copy of the receipt may beretained by the casino or other entity selling the DVD to the player.

In step 2240, an indication of the sale of the DVD is stored, along withthe activation code. For example, a database such as available DVDsdatabase 1000 of FIG. 10 may be accessed and the current date and timemay be stored in the date sold field. The activation code now associatedwith the DVD may also be stored in the record of such a database. Thestatus of the DVD may be set to “purchased” or another similar status.

FIG. 23 illustrates an example of a receipt 2300 that may be provided toa purchaser (e.g., to a player upon a purchase of a DVD by the player).The receipt 2300 includes a name of a casino (in area 2305) that mayindicate the casino at which the DVD was purchased, the casino at whichthe DVD may be redeemed, and/or the casino at which the session uponwhich the outcomes represented on the DVD were generated.

Area 2310 includes an example printed message informing the player thatthe receipt 2300 must be presented in order for the corresponding DVD tobe redeemed, as is consistent with some embodiments described herein.The receipt 2300 also includes (in area 2315) an indication of the dateand time at which the DVD was purchased.

Area 2320 of the receipt includes an indication of session informationdescribing various parameters (and values thereof defining the sessionupon which the DVD video presentation is based. For example, the examplesession information indicated on receipt 2300 includes the name of thecasino (“ABC CASINO”). For instance, the name may refer to, for example,a casino at which the DVD was purchased, at which the DVD may beredeemed and/or at which the outcomes represented on the DVD weregenerated. The example session information further includes the game forwhich the outcomes represented on the DVD were generated (“DOUBLEDIAMOND”), and an indication of the wager per game play (“25¢-2 COIN”)posted for each game play represented on the DVD. Of course, differentand/or additional session information may be indicated on such areceipt.

The receipt 2300 also includes additional data (in area 2325) that maycomprise encoded information and/or human readable informationcorresponding to the DVD and/or session (e.g., a redemption value, POSand/or casino attendant associated with the sale, session and/or DVDtype, price of the DVD, etc.). In some embodiments, as indicated in area2330, a disc activation number may appear on the receipt 2300 in barcode and/or human readable form. The disc activation number maycomprise, for example, a disc activation code as described herein.

The receipt 2300 also includes a signature line (in area 2335) that maycomprise a line on which a player may be required to sign her name uponredeeming a DVD (e.g., as a measure preventing the player from claimingthat the player has not redeemed the DVD and/or to discourage the playerfrom attempting to re-use the receipt to again redeem the DVD). One ormore other lines and/or boxes may be included (e.g., as depicted in area2340) to be filled in by a casino attendant and/or a player upon a DVDbeing redeemed. For example, information relating to the authorizationof the redemption, the date and/or time of the redemption, a slot clubmembership number of a player, an indication of whether the purchaser isa member of a slot club, and/or the signature of the purchaser and/orcasino attendant facilitating the redemption may be filled in.

The receipt 2300 further includes a prize claim code (in area 2345). Theprize claim code may comprise, for example, a barcode and/or a serialnumber that corresponds to a location to find pertinent informationstored in a database. For example, the barcode may be scanned to obtaina prize claim code that may be a pointer to a record of a database thatstores an indication of the redemption value of the DVD. In someembodiments, the prize claim code may comprise a disc identifier and/ora session identifier, as these are described herein.

According to one embodiment, as discussed in this disclosure, a ticket(e.g., ticket 2905 FIG. 29) may be provided to a player as a proof ofpurchase and/or to use to redeem a payment associated with a DVD orother tangible medium. For example, a TITO ticket (measuring 2.5″×6″; orapproximately 6.35 cm×15.24 cm) or other medium similar in appearance toconventional cashless gaming tickets may be printed and provided to aplayer (e.g., upon the player's purchase of a DVD). In one example, theprovided receipt is identical in size to a standard cashless gamingticket and includes a barcode (e.g., a prize claim code). One or moresuch tickets may be provided to a player (e.g., being associated withidentical or different redemption values or portions of a totalredemption value of a set of purchased outcomes) for redeemingpayment(s). Similarly, in some embodiments, different players associatedwith the same purchased product (e.g., a DVD) may receive identical ordifferent tickets.

In one embodiment, unlike conventional cashless gaming tickets, a ticketprovided as a receipt might not indicate an associated prize orredemption amount in text (in contrast to the example ticket 2905).Players may redeem winnings by inserting such tickets into a GD, kiosk,or other device configured to receive such tickets (e.g., employing TITOtechnology). For example, a GD may read or otherwise receive a barcodeprinted on a ticket and look up associated information to verify, forexample, that a DVD was legitimately purchased and/or whether an attempthad been made previously to redeem a DVD. Some examples of suchfunctionality are discussed with respect to process 2700. As discussedin this disclosure, in some embodiments one or more players must beregistered or otherwise associated with a receipt, voucher, or purchasedproduct. In such embodiments, a redemption process may include requiringa redeemer to provide some type of identification at the device at whichthe redeemer presents the ticket. For example, a player may be promptedto insert a player tracking card at a kiosk or GD in order to verifythat the player is associated with a particular ticket.

In one embodiment, a player who purchases a DVD may return to the casinoat which the DVD was purchased. By presenting any or all of a (i) a discidentifier, (ii) activation code, (iii) receipt and/or (iv) valid photoidentification, the player may be able to redeem the DVD for theredemption value of the DVD (typically the end credit meter balance ofthe session on which the DVD video presentation was based). The playermay, for example, collect a redemption value of a DVD from one or moreof (i) a casino attendant operating a computer device (e.g., POS 320 orCPD 325), (ii) a kiosk operable to facilitate the redemption of DVDs(e.g., by receiving a session identifier and/or other relevantinformation via an input device, accessing a database, and determining afinal session balance or redemption value associated with the DVD) (iii)a GD, and (iv) another device. A redemption value may be provided to aplayer, for example, in the form of cash, voucher, gaming credit, or anyother form. In some embodiments, players may be given an incentive toreturn to a casino to redeem DVDs (e.g., casinos may recognize thatdrawing customers back to their property may lead to increased gamblingactivity and thus increased revenues). For example, if a player is due afinal session balance of $63.25, the player may be offered an amountmore than the final session balance (e.g., an additional $10) to redeemthe DVD at the casino (e.g., rather than having a check for theredemption value of the DVD mailed to the player).

In one embodiment, a player may redeem a DVD without returning to thecasino at which the DVD was purchased. For example, a player may contacta casino after viewing a video presentation (e.g., via postal mail,phone, fax, e-mail, a form of a casino Web page, etc.) and indicate asession identifier, disc identifier, activation code and/or some otherinformation (e.g., a home phone number) by which a casino may determinea final session balance or other redemption value due to the player. Inone embodiment, the player may be given an opportunity to specifywhether the player prefers to be mailed a check, to have fundstransferred in some electronic manner (e.g., funds are transferredelectronically to a player's financial account) or to have theredemption value provided to the player in some other manner.

In some embodiments, a player may not contact a casino after purchasinga session. In one such embodiment, if a player is owed a final sessionbalance based on the purchased session, the casino may wait apredetermined period of time after the purchase of the DVD associatedwith the session. If this period of time (e.g., 30 days) elapses and nocontact is received from the player (e.g., the player does not return tothe casino to redeem the DVD), the casino may automatically issue anyfunds owed to the player (e.g., by mailing a check to a provided addressor storing the funds in a financial account associated with the player).

In some embodiments, although a redemption value greater than zero maycorrespond to a session purchased or provided to a player and a pricemay be associated with the session, the player may have not yet paid theprice at the time he requests the redemption value. Accordingly, in someembodiments, the price of the session may be deducted from theredemption value. If the redemption value is greater than the price, theplayer may be paid the difference. If however, the redemption value isless than the price, the player may be paid nothing.

In some embodiments, a session may end with a negative balance (e.g., atthe end of the session, the sum of wagers deducted from a startingcredit meter balance exceeds a sum of payouts added to the startingcredit meter balance). In some embodiments, such negative balances maybe treated similarly to a balance of zero credits; in other words, theredemption value of the session may be zero.

It should be noted that, in various embodiments, a player may have anopportunity to redeem a DVD without having watched the videopresentation recorded on the DVD in its entirety (or at all). Forexample, a player may purchase a DVD containing a video presentation,but may not have a chance to watch the video presentation before hisnext trip to the casino. In some embodiments, such a player may beallowed to redeem the DVD irrespective of the failure to watch the videopresentation. However, in other embodiments, a player may not be allowedto redeem a DVD unless the player provides a special code output upon(e.g., during) the conclusion of a video presentation recorded on theDVD (e.g., an alphanumeric code or password is displayed during or aftera final game play result is depicted).

In some embodiments, as described with respect to FIG. 27, a DVD orother tangible medium may only be presented for redemption once, mayonly one have one associated redemption value, and/or may be redeemed byonly one person (e.g., having a valid receipt or activation codecorresponding to the DVD).

In other embodiments, as described further below, a DVD or othertangible medium may have multiple associated redemption values and/ormore than one player may be eligible to receive a redemption valueassociated with a plurality of outcomes. In one example, at least two ofthe redemption values associated with the same DVD may differ from oneanother. In some embodiments, a DVD may be redeemed more than once(e.g., corresponding redemption value(s) may be provided on differentoccasions). For example, a DVD may be redeemed multiple times by asingle customer, or may be redeemed by different customers (e.g., inrespective transactions). In one embodiment, a DVD may be associatedwith and/or may be redeemable by more than one individual. For example,a DVD may be redeemed/redeemable by any one or more of a plurality ofplayers of the DVD.

FIG. 24 illustrates an example of a receipt 2400 that may be provided toa purchaser (e.g., to a player upon a purchase of a DVD by the player).The receipt 2400 is almost identical to the example provided in FIG. 23,except that it includes two prize claim codes (areas 2445 and 2450) fora “RED” player and a “BLUE” player, respectively. Thus, in accordancewith some embodiments, a receipt, DVD, and/or plurality of outcomes maybe associated with more than one code for redeeming a prize and/or withmore than one player. Although only prize claim codes are depicted inreceipt 2400, various other additional or alternative information may beprovided for indicating that more than one player may be associatedand/or that more than one redemption may be made with respect to thepurchased product (e.g., DVD). For example, player identifiers may beprovided (e.g., where players are registered upon or after purchase of aDVD) in addition to or instead of a claim code.

FIG. 25 illustrates an example of a receipt 2500 that may be provided toa purchaser (e.g., to a player upon a purchase of a DVD by the player).The receipt 2500 is almost identical to the example provided in FIG. 24,except that it includes two prize claim codes (areas 2545 and 2550) onrespective portions of the receipt 2500 that may be easily separatedfrom one another and/or from the receipt 2500 using the perforations2552 and 2554. In this way, claim codes may be conveniently detached anddistributed to the plurality of players playing a particular DVD. Ofcourse, as discussed above with respect to receipt 2400, any of variousother types of information may be included or substituted for on thedetachable portions. In fact, in some embodiments, each portion mayinclude all of the same information and each may resemble the receipt2300 of FIG. 23 (with the exception, e.g., of any player-specificinformation, such as a prize claim code or player identifier). In thisway, more complete receipts may be separated and provided to individualplayers of the associated plurality of players.

FIG. 26 illustrates an example of a receipt 2600A and a receipt 2600Bthat may be provided for a plurality of players associated with apurchased plurality of outcomes. The receipts 2600A and 2600B may bevirtually identical, with the exception, e.g., of any player-specificinformation, such as a prize claim code or player identifier. In theexample receipts 2600A and 2600B, the prize claim codes differ for the“RED” and “BLUE” players (2645 and 2655, respectively).

In some embodiments where multiple indications of a prize claim codes,e.g. printed on separate or separable receipts are provided, the prizeclaim codes may be identical. In this way, each player may have a validcopy of the only prize claim code.

Referring now to FIG. 27, illustrated therein is a flowchart of anexample process 2700 for redeeming a DVD. The process 2700 may beperformed, for example, at a POS 320.

In step 2705 a request to redeem a DVD is received. For example, aplayer may approach POS 320 and provide the DVD to be redeemed (and/orpackaging and/or receipt or other documentation thereof) and request theredemption value of the DVD to be provided to the player. In anotherexample, a player may contact a casino or other entity that facilitatesthe redemption of purchased DVDs in another manner (e.g., via telephone,e-mail, the Internet, postal mail, etc.) to request the redemption of aDVD.

In step 2710, a unique identifier of the DVD is determined (e.g., basedon information provided in the request to redeem the DVD). For example,a disc identifier located on packaging of the DVD may be scanned in ortyped in by a casino attendant (in such embodiments a player may berequired to provide the DVD, or at least the packaging thereof, whenredeeming the DVD).

In step 2715, a code is received. For example, a casino attendant mayscan or type in the code. In one example, a receipt code (e.g., anactivation code printed on the receipt) may be received. In anotherexample, a unique receipt identifier uniquely identifying the receiptand/or transaction in which the receipt was issued is received. That is,in some embodiments a player may be required to provide (e.g., to acasino attendant) a receipt (or copy thereof for the purchase of a DVDwhen requesting to redeem the DVD. In some embodiments in which the codereceived in step 2715 is an activation code, the activation code for aDVD may have been provided to a player in a manner other than beingprinted on a receipt (e.g., it may have been provided to a player viae-mail, via another printed document, verbally, etc.). Accordingly, insome embodiments in which an activation code is required to redeem aDVD, step 2715 may comprise receiving the activation code in any mannerdesired and practicable and not necessarily via a receipt (in which casea receipt may or may not be required to redeem the DVD).

In step 2720, it is determined whether the DVD has been legitimatelypurchased. For example, a database or other memory structure storinginformation about DVDs previously purchased may be accessed. Forexample, the available DVDs database 1000 of FIG. 10 may be accessed andit may be verified that the disc identifier and activation codecorrespond to one another in the database and, further, that the statusof the DVD corresponding to the disc identifier is currently“purchased.” In one embodiment, POS 320 or another device performing theredemption process (e.g., a kiosk of a casino) may communicate with adevice storing such information (e.g., CS 305). In one embodiment, thePOS 320 or other device performing the redemption process may beoperable to determine whether the DVD was legitimately purchased byaccessing such a database and verifying the information received insteps 1305-1315. In another embodiment, the POS 320 or other deviceperforming the redemption process may forward the information receivedin steps 1305-1320 to another device (e.g., CS 305) storing informationuseful in verifying the legitimate purchase of the DVD and determinethat the DVD was legitimately purchased upon receiving an authorizationmessage or indication from this other device.

If it is determined that the DVD was not legitimately purchased, amessage indicating an inability to redeem the DVD is output in step2730. For example, a message indicating that the system is “unable toconfirm previous purchase” may be output (e.g., to a player attemptingto redeem the DVD and/or to a casino attendant facilitating theredemption process, who in turn may communicate this information to theplayer) and the redemption of the DVD may be denied. Otherwise, theprocess 2700 continues to step 2725.

In step 2725, it is determined whether the DVD has previously beenredeemed. This step may be performed to prevent “double dipping” or anattempt by a player to redeem a DVD more than once. For example, anappropriate database may be accessed (e.g., such as the available DVDsdatabase 1000 depicted in FIG. 10) to determine whether the status ofthe subject DVD is set to “redeemed” or to another status indicatingthat the DVD has previously been redeemed (or if a previous successfulredemption of the DVD is otherwise stored in a memory). In oneembodiment, POS 320 or another device performing the redemption process(e.g., a kiosk of a casino) may communicate with a device storing suchinformation (e.g., CS 305). In one embodiment, the POS 320 or otherdevice performing the redemption process may be operable to determinewhether the DVD has previously been redeemed by accessing an appropriatedatabase and confirming whether information stored in the databaseindicates that the DVD has previously been redeemed. In anotherembodiment, the POS 320 or other device performing the redemptionprocess may forward the information received in steps 1305-1320 toanother device (e.g., CS 305) storing information useful in determiningwhether a DVD has previously been redeemed and determine that the DVDhas not previously been redeemed upon receiving an authorization messageor indication from this other device. In some embodiments, thedeterminations of steps 2720 and 2725 may be performed in a single stepand/or by a single device.

If it is determined that the DVD has already been redeemed, a messageindicating an inability to redeem the DVD is output in step 2730. Forexample, a message indicating “previously redeemed” or anotherappropriate indication may be output (e.g., to a player attempting toredeem the DVD and/or to a casino attendant facilitating the redemptionprocess, who in turn may communicate this information to the player) andthe redemption may be denied. Otherwise, the process 2700 continues tostep 2735.

In step 2735, the redemption value of the DVD is determined. Forexample, a record of a database associated with the DVD may be accessedand the redemption value may be read from the database. In someembodiments, the redemption value may be encoded on the DVD itselfand/or packaging thereof and may be read therefrom (e.g., in addition toor in lieu of accessing a database storing such information).

In step 2740, the redemption value is provided to a player. Asdescribed, a redemption value may be provided to a player in manydifferent forms and in a variety of different manners. For example, cashmay be handed to the player by a casino attendant or dispensed from akiosk. In another example, a cashless gaming receipt that may beredeemed at a casino booth or be used for wagering at a GD may beprovided, the value of the receipt being based on the redemption value.In yet another example, a check may be mailed to a player. In anotherexample, an electronic and/or financial account associated with theplayer may be credited based on the redemption value. In someembodiments, a redemption value may correspond to a physical prize to beprovided to the player (e.g., a coupon, piece of jewelry, discountbooklet, gift certificate or other tangible item). In such embodiments,step 2740 may comprise authorizing a casino attendant to provide theprize to the player. Step 2740 may further comprise storing anindication of the successful redemption of the DVD in a memory (e.g., astatus field of the available DVDs database 1000 of FIG. 10 may be setto “redeemed”), to prevent the player from redeeming the DVD a secondtime. Alternatively, such a step of storing an indication of thesuccessful redemption of a DVD may be a distinct step of process 2700.

6. Additional Description of Some Embodiments Related to a Plurality ofPlayers

Various gambling games involve play between a plurality of players, orat minimum, a social setting in which a plurality of playersparticipate. For example, in various games such as poker (e.g., TexasHold'Em) or bingo, play is competitive. For instance, players may playagainst each other such that only one or more players of a group ofplayers may win a particular game, hand, round, and so on, while one ormore other players may lose. In other games such as roulette or craps,players may play against the house, or may wager on events or actions ofa third party. In such games, one player's win may not necessarilyconstitute another player's loss, but play of such games is nonethelesscommonly thought of as a social experience (e.g., multiple players “ridea hot streak” of a craps table together). Further, Applicants recognizethat there may be a need for further gambling games offering competitiveplay (or the simulation of competitive play) or other styles ofmultiplayer or social play to patrons.

Accordingly, in some embodiments, systems, apparatus, and methods arecontemplated for producing and/or providing game discs that depict gameplay by a plurality of players. For example, methods are contemplatedfor representing simultaneous or concurrent play of a game, hand, round,or the like, by two or more players.

In some embodiments, an outcome for a player is generated for a game,hand, round, or the like, in which the outcome depends on anotheroutcome that was previously determined for the same game, hand, orround. The previously determined outcome may have been for a differentplayer. For example, a first outcome may correspond to an initial handof cards dealt to a first player from a standard deck of cards, and asecond outcome may correspond to an initial hand of cards dealt to asecond player from the same deck, after the first player's initial handwas dealt.

In some embodiments at least one actual player (a person) is associatedwith at least one respective simulated player depicted on a game disc.In some embodiments, each of a plurality of players is associated with arespective simulated player of a game disc.

In some embodiments, a game disc (or other tangible medium) may beprovided to and/or for play by a plurality of players (e.g., one or moreplayers may purchase and/or view game play results on a game disc). Insuch embodiments, the game disc may depict play of a game by one or moreplayers. For example, the game disc may provide only one set ofindications of game results associated with a depicted “LUCKY LUKE”player, or may provide multiple sets of indications of game results(e.g., a first set associated with a “RED” player and a second setassociated with a “BLUE” player).

In some embodiments, one or more players legitimately may claim winningsassociated with the same game disc(s).

In some embodiments, methods and systems are provided for (i)determining one or more winning players associated with a game disc(e.g., a multiplayer game disc), and/or (ii) determining an amount ofwinnings associated with one or more winning players of a game disc.

In some embodiments, methods and systems are provided for indicating(e.g., to a viewer), based on one or more specified rules or guidelines,(i) one or more winning players, and/or (ii) an amount of winningsassociated with one or more winning players.

In some embodiments, one or more media files may be created, identifiedand/or stored on a game disc or other tangible medium for indicatinggame results and/or final session balances associated with one or moreplayers for a single game disc. For example, a database of media filesmay be accessed in a manner such that desired files may be retrieved,encoded into a proper format, and stored on a DVD). For instance, whencreating a game disc in a DVD format one or more media files may beidentified and encoded (e.g., as an MPEG-2 file), such that audio/videomay be read, decoded and/or output by an appropriate device.

In some embodiments, systems, apparatus, and methods are contemplatedfor producing game discs (or for providing indications of game resultsin any other manner described herein) enabling multiplayer play.

In some embodiments, a game disc may comprise a plurality of sets ofindications of game results, each set associated with a particularplayer. As described further herein, players might be identified by aparticular number, color, position, icon, graphic, and/or in any othermanner. For example, a first set of indications of game results may beassociated with a first player (e.g., a first series of slot machinespins belong to a “RED” player), and a second set of indications of gameresults may be associated with a second player (e.g., a second series ofslot machine spins belong to a “BLUE” player).

In one embodiment, a multiplayer game disc may indicate game resultsand/or final session balances associated respectively with one or moreplayers of the multiplayer game disc.

According to one embodiment, one or more multiplayer game discs may beprovided to a plurality of players, and only one or more players of theplurality may claim winnings or a portion of winnings associated withthe one or more discs. The determination(s) of which player(s) of theplurality may claim any portion of winnings may be based, for example,on the indications of game results associated with the players (e.g., a“RED” player may win or lose based on an associated set of indicationsof game results).

In some embodiments, one or more players in a group may compete for oneor more prizes indicated by one or more game discs. For example, suchgame discs may include indications of game results (e.g., in a videopresentation as described in this disclosure) that may be associatedwith individual players. For example, a “two-player” slot machine-themedgame disc may be created, such that one set of reels may be associatedwith a first player (e.g., a “RED” player) and a second set may beassociated with a second player (e.g., a “BLUE” player). At the end ofthe disc (e.g., at the end of a video presentation of slot machine spinsfor the players), the player with the highest credit balance may bedetermined to be a winner (and may therefore be entitled to a prize, aswill be described). Various such embodiments are contemplated and someexamples are described in this disclosure.

Various methods of (i) generating game results and (ii) determiningindications of game results based on the generated game results arecontemplated with respect to discs associated with a plurality ofplayers. For example, in some embodiments, a plurality of gamingsessions may be simulated or otherwise executed (e.g., two sessions),such that the results of the sessions may then be associated with asingle game disc (e.g., a two-player game disc).

A plurality of automated gaming sessions may be executed according tovarious parameters, as described herein. For example, as discussed withrespect to step 105 of process 100, a GD may be programmed to executeone million sessions defined by a set of particular parameters (andvalues thereof).

In one embodiment, a reference run (e.g., of a plurality of sessions)may be executed such that a batch of slot machine-themed game discs maybe created based on the session result data. For example, one millionautomated sessions may be simulated or otherwise executed. The sessionsmay be simulated (e.g., by a computer device comprising software thatsimulates or models game play of various gaming devices, as described)according to the following exemplary parameters: (i) a particular slotmachine model with particular active pay combinations and probabilitiesis chosen (computer software models a popular “Big Purple Martians” slotgame), (ii) a particular wager amount per game play is chosen (e.g.,such that consistently, 25¢ will be bet per spin), (iii) a particularstarting balance is chosen (e.g., 80 credits of 25¢ each), and (iv) aparticular session duration and/or one or more terminating conditionsare identified (e.g., game play will continue until 500 spins areexecuted or a credit balance reaches zero, whichever comes first).Accordingly, one million gaming sessions may be simulated such that onemillion individual final session balances may then be determined.

Indications of game results (e.g., representative outcomes) may then bedetermined in association with one or more multiplayer game discs basedon the final session balances indicated by the reference run. Forexample, it may be determined that 500,000 two-player slotmachine-themed game discs may be created based on the one million finalsession balances determined by the reference run. Thus, each disccreated according to this example process may comprise a plurality ofsets of indications of game results (e.g., two sets), each set having arespective indicated final session balance (e.g., two separate finalsession balances are indicated). Each final session balance may then beassociated with a particular player, such that one or more winningplayers may be determined (as described further herein).

Of course, various other methods of generating game results and/or finalsession balances are contemplated. For example, rather than use acomputer device with software for simulating game play (e.g., AS 310),one or more actual GDs may be used, as described in this disclosure.Further, in some embodiments, rather than arrive at a final sessionbalance by means of simulating or otherwise executing a game session, afinal session balance may be randomly determined in some other manner(e.g., a random number is generated between a range of random numbersindicating final session balances).

Indications of game results may then be determined based on thegenerated game results and/or final session balances of the batch run ofsessions. For example, in some embodiments, as described in thisdisclosure, actual game results or outcomes may be considered whendetermining indications of game results. For example, a game disc or DVDmay indicate a record of the actual outcomes determined in an associatedreference run. For example, a two-player game disc may indicate twofinal session balances, each associated with a particular slot machinesession, and each slot machine session may indicate game results as theywere actually achieved.

In other embodiments, alternate indications of game results (e.g.,representative outcomes) may be determined as described herein (e.g.,rather than display an outcome-by-outcome record of game results,different indications of game results are selected that ultimatelyindicate a desired final balance). It should be noted that, in someembodiments, it may be desirable to determine alternate indications ofgame results in association with discs depicting play by multipleplayers. For example, it may be desirable to indicate game results fromtwo separate sessions simultaneously or concurrently (e.g., two sets ofreels, one for a first player and one for a second player, spinside-by-side or adjacent to each other in some other manner), such thatthe representation of the sessions can be assured to conclude at thesame time. For example, if during an executed run a first sessionreaches a balance of zero credits before 500 game plays have elapsed(thus terminating play) and a second session concludes with a positivecredit balance after 500 game plays, alternate indications of gameresults may be determined in association with a first session such thatthe first and second sessions may conclude at the same time ifindications of game results thereof are output concurrently.

As discussed in this disclosure, in some embodiments a plurality of gamesessions (e.g., or a reference run) may be simulated or executed inadvance, such that the results and/or final session balances thereof maybe considered when creating game discs (e.g., multiplayer game discs).For example, a pool of one million final session balances may then beused to create multiplayer game discs (e.g., 500,000 two-player gamediscs; 250,000 four-player game discs, and so on). Thus, in someembodiments, a first and second session of game results may ultimatelybe associated with a single game disc for multiple players, even thoughthe two sessions may be simulated or otherwise executed at differenttimes or in an otherwise individual manner. For instance, during areference run, a computer simulates a first session, and once the firstsession is complete, simulates the second session, and so on.

Thus, in accordance with some embodiments, when creating a game discassociated with more than one player and/or more than one session, finalsession balances and/or actual game results associated with a pluralityof previously-generated sessions may be (i) determined randomly (e.g.,two particular final session balances are selected at random from a poolof one million final session balances associated with a reference run),or (ii) selected according to various other methodologies (e.g., twofinal session balances are identified and selected consecutively from adatabase of stored final session balances). It should be noted that itmay be preferred (but not required) that the same applicable sessionparameters be used when simulating or otherwise executing each of theplurality of sessions (e.g., such that for a game disc presenting twosimultaneous slot machine sessions, each session starts with the samecredit balance, has the same wager amount per game play, and so on).

The generation of the results for respective player sessions may beperformed generally independently for some types of games, in particularwhere no outcome for one player or session is necessarily dependent onany outcome determined for another player or session. For instance, ingames such as keno, roulette, or slots, the play of a first player doesnot necessarily affect the game results and/or payouts achieved by asecond player, and the generation of respective game results anddetermination of respective indications of game results may be performedgenerally independently.

However, in other types of casino games described further herein, play(or existence) of a first player may affect the game results and/orpayouts achieved by a second player. Accordingly, in some embodiments,when simulating or otherwise executing a plurality of game sessions, thegame results and/or final session balances of which may later be used tocreate one or more multiplayer game discs, such sessions may besimulated or executed in a concurrent and/or dependent manner, such thatthe play (or existence) of a first player may appropriately affect thegame results and/or payouts achieved by a second player in accordancewith the particular rules of the game.

For example, in the game of bingo, a first and second player must beplaying at the same time (e.g., in the same game or drawing) in order toaccurately determine a winner between the two players (e.g., in order todetermine which player achieves a particular pattern first, bothplayer's cards must be compared to the same set of randomly-drawnnumbers). Thus, in some embodiments, when generating game results, suchas by simulating or otherwise executing a plurality of gaming sessionsof a reference run, a plurality of players may be considered. In otherwords, when creating multiplayer game discs for casino games wherein theplay (or existence) of a first player affects the payouts and/or gameresults achieved by a second player, simulations of such games mayapproximate a multiplayer environment, such that payouts and/or gameresults may be determined in an appropriate manner.

According to some embodiments, a computer device (e.g., AS 310, a GD) ofthe present invention may comprise software for simulating a pluralityof sessions of a multiplayer game such as bingo. For example, such asoftware program may be configured to simulate one million sessions of agame of bingo, according to various parameters, including but notlimited to (i) a number of players per game (e.g., four players pergame), (ii) a session duration, such as a number of games per session(e.g., 25 games per session), (iii) one or more specified game types orplay patterns per session (e.g., 12 games will be standard “bingo”games, five games will be for a pattern of “four corners,” five gameswill be for an “x-shape” pattern, three games will be for a “blackout”pattern, and so on), (iv) payouts associated with one or more game typesor patterns (e.g., achieving a blackout always pays 40 credits; or, inanother example, achieving an “X” pattern in balls 10 drawn or fewerpays a first amount of credits, whereas achieving an “X” pattern in11-14 balls pays a second, lesser amount of credits; and so on), (v) amanner in which the numbers indicated by cards of one or more playersmay be determined (e.g., in association with each column of a bingocard, five numbers within a particular range may be randomly determined;from this, an entire card of numbers may be established for a particularplayer, and this card may be used repeatedly from game-to-gamethroughout a session, or a new card may be randomly determined in such amanner for each game of the session), (vi) a starting credit balanceassociated with one or more players (e.g., zero credits), (vii) a wageramount per game play associated with one or more players (e.g., eachplayer wagers a $1 credit per game), (viii) an indication of whether ornot a credit balance may go negative, and if so, how far negative it maygo (e.g., negative without limit).

Accordingly, a multiplayer bingo game may be simulated in this regard,as numbers (commonly represented in physical fashion by balls in ahopper) may be randomly determined or drawn and matched against aplurality of player cards to determine one or more winning playersand/or payout amounts such one or more winning players may haveachieved. For example, a first player (represented by a first cardcomprising randomly determined numbers) may win a first game by beingthe first to achieve a particular pattern, thereby potentially winningan amount of credits (e.g., the size of the payout relative to thenumber of balls drawn), whereas a second player may win a second game bybeing the first to achieve a particular pattern, and so on. Thus, assuch simulated players may lose credits through wagering and/or wincredits through game play, credit balances associated with the playersmay change, such that at the end of the simulated session, a finalsession balance may be associated with each simulated player (e.g., afirst simulated player has achieved a final session balance of threecredits, a second simulated player has achieved a final session balanceof −10 credits, a third simulated player has achieved a final sessionbalance of 77 credits, and so on).

In some embodiments, a plurality of final session balances may bedetermined by simulating a particular session of a reference run, inwhich each final session balance is associated with (or will beassociated with) a particular simulated player. It should of course benoted, however, that other means of generating game results and/ordetermining final session balances of such a multiplayer bingo game maybe utilized (e.g., a hopper device with physical balls is used, etc.).Some other ways of determining outcomes and balances are discussed inthis disclosure. Further, as described herein, single-player versions ofsuch a bingo product are contemplated.

As discussed above, multiplayer game discs may be created (e.g.,indications of game results may be determined and stored on a game disc)based on the game results achieved and/or final session balances. Forexample, in some embodiments, actual game results achieved during suchsessions of reference runs may be utilized (e.g., as described, suchgame results are stored in a physical and/or electronic manner, suchthat they may be accessed or otherwise considered when determiningindications of game results), such that associated game discs may depictan outcome-by-outcome and/or game-by-game record of what transpiredduring an associated session of a reference run.

In other embodiments, as discussed in this disclosure, alternateindications of game results (e.g., representative outcomes) may bedetermined. For example, a simulated session of a reference run mayindicate that after a series of 25 bingo games, a first player finisheswith a balance of three credits, a second player finishes with a balanceof −10 credits, a third player finishes with a final session balance of77 credits, and a fourth player finishes with a balance of 15 credits.Accordingly, alternate indications of game results may be determined, solong as the indications ultimately depict the appropriate final balancesin association with one or more players, for example.

In some embodiments, as described further herein, a payout associatedwith a multiplayer game disc may be provided only to a player with thehighest final credit balance (e.g., in a “winner-take-all” or “pays bestplayer only” multiplayer game disc). Accordingly, in some embodiments,representative outcomes may be determined so as to depict an exact finalsession balance in association with the highest final session balanceachieved during the simulated multiplayer session (e.g., referencing theabove example, the third player who finished with a balance of 77credits), while alternate indications of game results determined inassociation with the other simulated players may ultimately depict anyfinal balance less than the highest final session balance of thesimulated multiplayer session. For example, so long as a four-playergame disc having a “pays best player only” redemption process indicatesthat the third player wins 77 credits, the game disc may depict that theother three players have won any amount of credits that is less than 77,such final balance amounts being irrelevant considering that only theplayer with the highest balance is entitled to any winnings for thatparticular game disc.

Some additional description of various methods of (i) generating gameresults (e.g., simulating or otherwise executing one or moresingle-player or multi-player game sessions), (ii) determining one ormore final session balances (e.g., a plurality of final sessionbalances, each associated with a particular simulated player), and/or(iii) determining indications of game results based on the game resultsand/or final session balances (e.g., specific methods for determiningalternate indications of game results), are described in this disclosurewith respect to other casino games.

Thus, some embodiments may comprise providing indications of gameresults in association with an automated session that has been simulatedor otherwise executed with respect to a multiplayer casino game. In someembodiments, such indications of game results may be provided via a gamedisc (e.g., a DVD). Of course, in other embodiments, such indications ofgame results may be provided in some other manner (e.g., transmittedelectronically via the Internet, transmitted electronically to a mobilecomputing device, viewable via a software application, and so on). Forpurposes of facilitating description, however, several embodiments ofproviding such indications of game results via a game disc in DVD formatwill now be described.

Various methods for storing indications of game results on a medium suchas a DVD have been described herein. For example, one or more computerdevices described herein (e.g., AS 310) may access one or moreappropriate media files from a database (e.g., media file database 525),and encode the DVD such that the one or more media files may be viewablewhen the DVD is inserted into an appropriate reader device. Thus, insome embodiments, it may be desirable to create media files that, whenviewed by a plurality of players, indicate game results and/or creditbalances associated with a plurality of players. For example, varioustext, graphics, indicia, coloring, positioning or other techniques maybe utilized such that a clear visual association may be made between oneor more indications of game results and an associated player. Forexample, a four-player slot machine-themed game disc may display a gamescreen comprising four sections or quadrants, one for each player, suchthat each section or quadrant displays a particular set of reels, whichmay be animated so as to present indications of previously-generatedgame results. Further, each section may comprise a credit balance meterassociated with a particular player, such that players may track andcompare their results.

Various methods are contemplated for creating a visual associationbetween one or more indications of game results and a particular player.Following are some examples of elements that may be associated with aparticular player and/or one or more indications of game results: (i) aparticular color (e.g., a blue background appears behind cards dealt toa first player, a red background appears behind cards dealt to a secondplayer); (ii) a particular number (e.g., Player #1, Player #2, etc.);(iii) a particular position (e.g., the left player vs. the rightplayer); (iv) a particular name or other text (e.g., “Bob” vs. “Frank”);and (v) a particular avatar, character or other image (e.g., a cartooncharacter resembling an oil tycoon represents a first player, a cartooncharacter of a dog represents a second player, and so on).

In various embodiments, a plurality of such media files indicatingmultiplayer game results may be generated and/or stored by a GD and/orother computer device (e.g., AS 310) of the present invention. However,it is understood that unlike with many single-player games for whichconventional gaming devices may be widely available for use (e.g., whencreating a single-player, slot machine-themed game disc, the same mediafile output by a conventional video slot machine may be utilized as anindication of a game result when creating a game disc), it is possiblethat such conventional devices may not yet be available for the purposesof borrowing elaborate, multiplayer animations of game results.Accordingly, in some embodiments, as described, a software program ofthe present invention may serve to generate and/or store such desiredmedia files depicting particular game results.

Thus, in some embodiments, one or more media files may depict aplurality of indications of game results in a substantially simultaneousmanner, with a first indication associated with a first player, a secondindication associated with a second player, and so on. For example, amedia file may be created or otherwise retrieved, and the media file maydepict (i) four bingo cards, each associated with a particular player,as well as credit balances and other applicable data; (ii) a drawing ofa ball from an animated hopper, the ball revealing a particular number,and (iii) the daubing of one or more of the bingo cards based on thenumber drawn, such that a square of one or more cards may be markedappropriately.

Thus, in some embodiments, one or more players viewing such amultiplayer game disc may view a plurality of indications of respectivegame results that are output in a substantially simultaneous manner. Ofcourse, as described further herein, games other than slots and bingoare contemplated, such that players may similarly view a plurality ofblackjack hands, a plurality of Pai-Gow Poker hands, and so on.

In some embodiments, a game disc (or any other manner of providing suchindications of game results) may be formatted such that indications ofgame results associated with particular players may be provided in amanner other than simultaneously. For example, in one embodiment, suchindications of game results may be stored on a multiplayer game discsuch that they may be viewed alternately or successively (e.g., when thedisc is played, one or more indications of game results associated witha first player are output after one or more indications of game resultsassociated with a second player are output).

In some embodiments, players may utilize a menu screen of a DVD (or,similarly, a menu of a software application or Web site) for selectingoptions for how game results (for any number of players are provided. Insome embodiments in which one or more sessions of a multiplayer game aresimulated or otherwise executed, indications of game results associatedwith particular players may be separated and viewed individually (e.g.,separate media files are stored as separate chapters). For example, aplayer may select an option such that only indications of game resultsassociated with a particular player are output (e.g., a menu option for“View Player #1's game results” is selected, such that a particularchapter is accessed). In one example, several of such chapters or tracksmay be available, each associated with a particular player, such thatplayers may view individual sets of indications of game results asdesired.

Various methods are contemplated for determining one or more winningplayers and/or an amount of winnings associated with one or more winningplayers in association with a game disc (e.g., a multiplayer game disc).For example, in some embodiments, one or more winning players and/or anamount of winnings associated with one or more winning players may bedetermined in association with a particular multiplayer game discaccording to various criteria associated with game play, game resultsand/or a final session balance.

For example, in some embodiments, one or more players of a multiplayergame disc may be entitled to claim an exact final balance as indicatedby a game disc. In one embodiment, each player of a multiplayer gamedisc may be entitled to claim any winnings associated with theparticular player. For example, a final session balance associated witha first player as indicated by a credit meter may be 70 credits, suchthat the first player may be entitled to 70 credits, whereas a finalsession balance associated with a second player as indicated by a creditmeter may be 35 credits, such that the second player may be entitled toclaim 35 credits.

In another embodiment, only players who achieve a credit balance aboveand/or below a particular threshold may be entitled to claim winnings asindicated by a game disc (e.g., any players who win more than 40 creditsmay be entitled to keep them). Of course, as described, in someembodiments, a credit balance associated with one or more players may beallowed to go negative (e.g., such that any balance below zero creditsmay pay nothing, though a player may owe nothing other than a purchaseprice of a game disc).

In some embodiments, only one or more players of a multiplayer game discmay be entitled to claim an amount of winnings. For example, in someembodiments, only the player achieving the highest final session balancemay be entitled to an amount of winnings. In one example, a first playermay achieve a final balance of 31 credits and a second player mayachieve a final balance of 47 credits, and therefore the second playermay claim 78 credits (e.g., in a “winner-take-all” disc, the totalamount of winnings from both players may be claimed by the player withthe highest balance). In another example, a first player may achieve afinal balance of 31 credits and a second player may achieve a finalbalance of 47 credits, and therefore the second player may claim onlyhis winnings of 47 credits, whereas the second player may claim nothing(e.g., the game disc “pays best player only”). Thus, a variety ofembodiments are contemplated wherein one or more players may claim anamount of credits/winnings as indicated by a multiplayer game disc.

It should be noted that the manner in which one or more players mayclaim winnings associated with a game disc may affect the pricing of agame disc sold for a flat rate (or a flat rate remote gamingcontract/session offered in any other manner described herein). Forexample, a “winner-take-all” multiplayer game disc may be generally moreexpensive for a casino to offer than a multiplayer game disc that “paysbest player only.” Thus, in some embodiments of the present invention,an average cost of providing various types of such game discs or remotegaming contracts/sessions may be calculated by means of mathematicalsimulation. For example, according to a computer simulation, if10,000,00 multiplayer reference sessions are executed according tocertain parameters, it may be determined that the average amount ofwinnings indicated by such multiplayer game discs may be $29.94 (e.g.,on average, one player or a combination of players are paid $29.94).Accordingly, such costs may be considered when determining a flat rateprice for such discs. For example, such a multiplayer game disc may thenbe sold at a flat retail price of $39.99, insuring a long-run profitbased on mathematical simulation (e.g., though some discs may payplayers more or less than $29.94, on average an operator will make$10.05 profit on each disc sold). Various methods of determining suchflat rate prices based on associated costs (e.g., estimated costs orsimulated “contract costs”) that may be useful in some embodimentsdescribed in this disclosure are described in Applicant'scommonly-owned, co-pending U.S. application Ser. No. 10/001,089, filedNov. 2, 2001, entitled “GAMING DEVICE FOR A FLAT RATE PLAY SESSION ANDMETHOD OF OPERATING SAME,” and U.S. Provisional Application No.60/637,338 filed Dec. 17, 2004, entitled “GAMING DEVICE OFFERING A FLATRATE PLAY SESSION AND METHODS THEREOF,” the entirety of which areincorporated herein by reference for all purposes.

In some embodiments, the number of players associated with (or whopotentially may be associated with) a multiplayer game disc may also beconsidered when determining a flat retail price for such a game disc (ormultiplayer remote gaming contract/session provided in some othermanner). For example, in some embodiments, such game discs may be pricedso as to facilitate or encourage the even division of a retail priceamong a plurality of purchasers. In other words, in some embodiments,game discs may be priced such that a group of players may equally splitthe purchase cost of such a disc, such that each player may stand anequal chance to benefit from any winnings the disc may offer.

Thus, in one example, a rule for determining pricing associated with aflat-rate multiplayer game disc may be that the retail price must beequally divisible by a number of players associated with the disc (e.g.,a number of players depicted on the disc), as well as greater than adetermined average cost of providing the disc (e.g., if a plurality offour-player bingo sessions are simulated such that an average cost of$29.94 is determined, the disc may be sold for an even $40). Suchpricing methodology may work particular well in conjunction with a“winner-take all” or “pays best player only” format, in thatessentially, one of the players may be guaranteed to win, and thereforethere may be significant incentive to split the cost of the disc.

In one example, each of four friends may agree to provide $10 toward thepurchase of a four-player game disc with a guaranteed payout, knowingthat one of them will win a payout as indicated by a final sessionbalance associated with a particular player (e.g., the “RED” player'sfinal credit balance is the highest, and therefore he wins). Each of thestakeholders in this example multiplayer game disc may is taking a risk(i) that the player may not achieve the highest final session balance,and (ii) that the highest final session balance may indicate an amountof winnings that is greater or less than $10.

However, in other embodiments, an amount of winnings associated withsuch a game disc may be not be equivalent to one or more final sessionbalances indicated by the disc. Various such examples are contemplated.In one example, one or more players may be entitled to claim an amountof winnings that is based on one or more final session balances, but notequivalent to one or more final session balances. For example, in someembodiments, one or more winning players, such as the player with thehighest final balance, may be entitled to claim a predetermined, fixedamount of winnings (e.g., the winner of each disc gets $30). Such anembodiment may be advantageous in an environment wherein discs arepriced and/or marketed such that a retail price may be split by aplurality of sub-purchasers. For example, a four-player disc may bepriced at $40, and offer a $30 guaranteed payout to one winning player.Thereby, four players may split the cost of the multiplayer disc, eachplayer with a chance to triple his “wager” (e.g., his $10 contributiontoward the total purchase cost).

In one embodiment, a predetermined prize or payout associated with agame disc may be determined based on a retail price and a number ofplayers. Such embodiments are not limited to game discs associated withmultiple players. For example, in some embodiments, a rule fordetermining a prize amount may be that the prize amount must be greaterthan the retail price of the game disc divided by the number of players,but not less than the retail price. For example, if a four-player gamedisc is sold for $40, a prize amount associated with the game disc maybe determined, according a semi-random measure similar to a prize matrixused in an instant lottery system, to be between $11 and $39. In otherembodiments, such a prize amount may be determined randomly given suchconstraints (e.g., between $11 and $39).

In another embodiment, one or more final balance amounts may be comparedto a table illustrating various amounts of winnings in association withvarious final balance amounts or ranges of final balances. For example,one or more players finishing with a final session balance of 40 creditsor fewer may win nothing, whereas one or more players finishing with afinal session balance between 40 and 80 credits may be entitled to claim$10 in winnings, and so on.

In yet another embodiment, one or more winning players may be entitledto one or more further game plays and/or game results. For example, theplayer with the highest final credit balance may be entitled to anadditional 50 slot machine spins, which may have been previouslygenerated such that indications thereof may be stored on a game disc, orwhich a player may execute in some other fashion (e.g., by returning toa casino).

In some embodiments, a minimum and/or maximum payout amount may beassociated with a game disc. Of course, such embodiments are not limitedto game discs associated with multiple players. In one example, asession of a reference run may indicate that no player of a multiplayersession finished with a balance of higher than $5.75, but the player whofinished with the highest balance may still be entitled to claim a“minimum prize” of $10. In some embodiments, such a minimum prize levelmay be determined based on a retail price associated with a game discand/or number of players associated with a game disc (e.g., if afour-player game disc is sold for $40, a minimum prize amount may be$11, or slightly greater than one fourth of the cost).

In some embodiments, as described, one or more “standby” indications ofgame results otherwise unavailable to a player may be “unlocked” orotherwise made available for viewing if a player fails to attain a finalsession balance equivalent to a minimum payout amount (e.g., if aminimum disc payout amount is $10, and the highest a particular playerachieves is $5.75, “standby” indications of game results may be outputuntil the player reaches the predetermined minimum balance of $10).

Of course, such embodiments featuring minimum game disc payout or prizeamounts may be used in conjunction with single-player game discs. Itshould also be noted that, in some embodiments, providing even a smallminimum payout amount in association with each game disc may bebeneficial for a casino in that players may return to a property toredeem such discs, and thereby gamble more while at the property. Insome embodiments, such a minimum payout amount may be tested so as todetermine an amount at which an acceptable percentage of discs arereturned. For example, if it is determined that a significantly largerpercentage of players redeem discs associated with a minimum payout of$1.25 than discs associated with a minimum payout of $1, it may bebeneficial for a casino to offer a slightly large minimum payout amountto gain traffic within the casino.

In still further embodiments, a determination of (i) a whether or notone or more players is a winning player, and/or (ii) an amount ofwinnings associated with one or more players may be based on variousother measurable criteria (other than credits won) indicated by a gamedisc (or other manner of remotely viewing previously-generated gameresults).

For example, in addition or as an alternative to considering one or morefinal session balances when making such determinations, one or more ofthe following measures may be used: (i) one or more symbols or indiciaattained or collected by a player (e.g., a winning player is the playerwith the highest total arrived at by adding the player's credit balanceand a number of lemon symbols achieved); (ii) one or more particulargame results achieved (e.g., a first player achieves seven“Plum-Plum-Plum” outcomes, whereas a second player achieves three; afirst player achieves four pushes in a game of Blackjack, whereas asecond player achieves eight; a first player achieves 104 winningoutcomes, irrespective of any associated payout amounts, whereas asecond player achieves 137); (iii) a percentage of credits won, gameresults achieved, and/or game indicia achieved or collected when dividedby a number of game plays (e.g., a first player's “winning percentage”is 42%, whereas a second player's winning percentage is 31%); and so on.Of course, it should also be appreciated that any combination of theabove-described methods may be employed. Further, determining the costsof providing multiplayer game discs characterized by such rules fordetermining winning players and/or amounts of winnings may be simulatedin a manner described above (e.g., by simulating the generation of asufficiently large number of such discs, an average cost is calculated,such that a flat price may be determined that considers the averagecost).

Thus, several methods are contemplated by which one or more players maylearn (i) which players are winning players for a particular game disc(or discs), and (ii) amounts of winnings that one or more players may beentitled to claim. For example, such may be evident to one or moreplayers viewing such a multiplayer game disc (e.g., it is clear that atthe disc's conclusion, a first player wins 74 credits and a secondplayer wins nothing, as such may be indicated by the disc). In otherembodiments, players may utilize other resources in making suchdeterminations. For example, indications of which players are winningplayers and/or amounts of winnings associated therewith may be madeavailable via a network such as the Internet (e.g., a player may providean identifier associated with a multiplayer game disc, such that theplayer may view such information). In further embodiments, suchinformation may be encoded or otherwise printed on a purchase receipt ofthe present invention (e.g., such that a player need not watch a gamedisc, but rather may ascertain winnings by viewing a ticket or othertype of receipt).

Various methods are contemplated whereby players may redeem or claimwinnings associated with one or more multiplayer game discs. Severalsuch methods will now be described in some detail.

In some embodiments, a multiplayer game disc may be purchased that maybe viewed by a plurality of players. For example, a four-player, slotmachine-themed game disc may be purchased by a first individual for $40,who may then receive $10 each from three friends, such that each of thefour individuals may have equally contributed to toward the purchaseprice of the multiplayer disc (e.g., each player spent $10). The fourindividuals may then view the disc (e.g., four friends simultaneouslywatch a television set connected to a DVD player), such that one or morewinning players and/or an amount of winnings may be determined (e.g.,after a predetermined number of 500 spins have been indicated, thedepicted “Player #4” attains the highest credit balance, and thus isentitled to claim his credit balance of 189 credits).

In some embodiments, only one player may be entitled to claim an amountof winnings (e.g., in a “disc pays best player only” or“winner-takes-all” format). Thus, in some embodiments, a player mayredeem such a game disc in any manner described previously. For example,a player may provide a code or identifier associated with a game disc,such as code or identifier indicated by a game disc (e.g., a barcodeand/or text imprinted upon the non-readable side of the disc), game discpackaging (e.g., a barcode and/or text imprinted upon liner materialinserted into a jewel case), a purchase receipt (e.g., a barcode and/ortext imprinted upon the receipt), a ticket, and so on.

In one example, a group of players collectively purchasing and/orviewing a multiplayer game disc may agree to provide a winning playerwith such necessary materials (e.g., the winner gets to hold on to apurchase receipt, such that the next time the winner is in a casino orother location where the receipt may be redeemed, the winner may presentthe receipt and claim a prize). Thereby, a winning player may present anappropriate identifier or code when claiming such a prize. An amount ofwinnings payable to such a player may be determined in a variety ofmanners as described herein (e.g., a casino representative scans abarcode or otherwise enters a code or identifier using a casinopersonnel device, and a database such as the session databases of FIGS.7A and 7B is accessed so as to determine an amount of winningsassociated with the game disc).

In some embodiments, such materials may be designed so as to facilitatesuch redemption. For example, in some embodiments, one or more purchasereceipts provided in conjunction with the sale of a multiplayer gamedisc may comprise a plurality of codes or identifiers (e.g., a pluralityof bar codes), each barcode associated with a particular player. Forexample, if a four-player game disc is sold, a single receipt maycomprise four barcodes (e.g., which may be separated by perforation suchthat they may be detached and distributed), each labeled in associationwith a particular player (e.g., adjacent to a barcode is text indicating“Player #1”).

In another example, four separate purchase receipts may be issued, eachone in association with a particular player. Thus, in some embodiments,various methods are contemplating for providing a plurality ofidentifiers or codes which players may then use when redeeming winningsassociated with a multiplayer game disc (e.g., one or more such receiptsmay be required during redemption).

In an alternate embodiment, one or more players purchasing such a gamedisc may provide various information (e.g., name, address, etc.) whenpurchasing such a disc, such that the information may be recorded (e.g.,in association with the purchased disc and/or session(s) thereof).Accordingly, when redeeming an amount of winnings associated with such adisc, one or more players may provide (e.g., by requirement) a form ofidentification (e.g., for verifying that the player is associated withthe purchase and/or disc and is authorized to redeem winnings). In someembodiments, such a form of identification (e.g., a driver's license, aplayer tracking card number) may be utilized when determining an amountof winnings payable to a player (e.g., a database is accessed based on adriver's license number).

In some embodiments, more than one player may be entitled to claim anamount of winnings associated with a multiplayer game disc. For example,a four-player game disc may pay the “best two players” (e.g., theplayers with the two highest final session balances may claim thosebalances), and thus two or more players may desire to claim winningsassociated with a single game disc. Accordingly, in some embodiments, atotal amount of winnings (e.g., the sum of the first player's winningsand second player's winnings) may be provided to any player presentingone or more codes and/or indicia (e.g., a barcode, a numeric “PrizeClaim Code,” etc.). In other embodiments, as described, each player mustpresent a code and/or identifier (e.g., barcode) associated with theplayer in particular (e.g., the actual player who selected or wasassigned to simulated “Player #1” presents his barcode, the actualplayer associated with simulated “Player #2” presents his barcode), suchthat a final session balance associated with the particular player maybe accessed (e.g., scanning of a barcode prompts a casino personneldevice of the present invention to access a database and determine anamount of winnings payable to a particular player). Of course,alternative methods other than presenting barcodes when redeeming suchwinnings are contemplated (e.g., players call a particular phone numberand provide such a code, provide such a code in another electronicmanner, and so on).

Thus, various embodiments are contemplated whereby one or more playersmay view a multi-player game disc, determine which players are winners,and then redeem an amount of winnings associated with the one or morewinning players.

Several embodiments or features described herein may help assure thefairness of claims to winnings stemming from multiplayer play. Forexample, if a first player purchases for $40 a four-player game disc,and then three other players provide the first player with $10 each(e.g., such that each of four players divide the cost of the discevenly), all four players may be entitled to their own particularreceipt, barcode and/or other material by which they may claim winnings(e.g., some other substrate bearing a code or identifier). Players mightnot provide such sub-payments before being provided with such materials(e.g., players of a multiplayer disc may simply provide sub-payments inexchange for such materials, with which they may claim any winnings theyare due, as indicated by the game disc).

In another example, a game disc may comprise a tamper-evident sealadhered to a readable side of the game disc, such that the disc may notbe viewed while the seal is attached (e.g., the seal is opaque andprevents an optical laser from reading the disc). In this manner, aplayer might not provide payment in conjunction with a multiplayer disc(e.g., payment to a friend to split the cost of a disc, payment at acasino) if a seal has been removed.

For example, in some embodiments, actual players may choose anassociated simulated player before a multiplayer disc is viewed (e.g., afirst player chooses “Player #3” as indicated by the disc), such thatthe actual player may be entitled to any winnings earned by a simulatedplayer of the disc. Thus, such a tamper-evident seal may be removed inthe company of all players to ensure that no single player has viewedthe disc preemptively (e.g., such that a first player determines thatthe simulated “Player #3” is the correct simulated player to choose). Ofcourse, it should be noted that in arrangements where the purchase priceof such a multiplayer game disc is divided by a plurality of players,such players may be friends or acquaintances, and therefore may not belikely to attempt to defraud other players (e.g., it may be unlikelythat a player steals a purchase receipt from the player's friend andattempts to claim such winnings).

It should also be noted that, in some embodiments, it is envisioned thatsuch multiplayer game discs may be purchased, viewed and/or redeemed byonly one player (e.g., a player may simply enjoy cheering for two setsof slot machine reels rather than one set, and therefore may purchase amultiplayer game disc as opposed to a game disc marketed forsingle-player play).

In some embodiments, a first game disc may be associated with a firstplayer, and a second game disc may be associated with a second player.One or more winning players may then be determined based on the gameresults and/or final session balances indicated by the discs. Forexample, a first video poker disc associated with a first player mayindicate a final session balance of 74 credits, whereas a second videopoker disc associated with a second player may indicate a final sessionbalance of 104, and therefore the second player may be entitled toredeem an amount of credits (e.g., 104 credits if the disc offers a“pays best player only” payout format; 178 credits if the disc offers a“winner-take-all” payout format). Thus, in accordance with one or moreembodiments, a first game disc may be associated with a second gamedisc. For example, a first game disc may be associated with a secondgame disc such that, as described above, whether or not the first gamedisc may be redeemed for a prize may depend on (i) a final sessionbalance and/or game results of the second game disc and/or (ii) a finalfinal session balance and/or game results of the first game disc.

Of course, it should be appreciated that only one player might purchase,view and/or redeem such discs. In other embodiments, a multiplayer discmay be “shared” or divided by a number of actual players less than thenumber of simulated players represented by the disc. For example, if thedisc is a four-player disc, two players may share the disc (e.g., afirst player and a second player agree that the first player will takethe results of simulated “Player #1′ and simulated “Player 3,” and thesecond player will take the results of simulated “Player #2” andsimulated “Player 4”).

7. Additional Description of Some Embodiments

As described, in various embodiments, players may purchase a game disc(e.g., from a casino), such that indications of previously-generatedgame results may be viewed remotely (e.g., away from a gaming deviceand/or computer device which generated the results). Winnings associatedwith the game results may then be claimed by players (e.g., as playersreturn to a casino and present a game disc, and/or associated packaging,purchase receipts, and so on).

Various embodiments described herein have considered processes forgenerating game results and outputting indications of game results viaone or more game discs, wherein the game results indicate play of a slotmachine game (e.g., a game comprising randomly determined symbols of aplurality of reels). However, it should be appreciated that due to thepopularity of other casino games, including games such as poker, craps,roulette, blackjack, and so on, it may be desirable to produce gamediscs indicating game results of such other casino games, even if gameresults of such games are not traditionally output in an electronicmanner within a casino (e.g., as in a game such as roulette).

Various gambling games offered by a casino may be categorized or dividedinto different groups or types. While examples for producing game discs(or remotely providing indications of game results in some other mannerdescribed herein, such as electronically via a network) in associationwith each of these games in specific will be provided, it is worthdescribing briefly the basic differences between these groups or types,and generally how these differences might lead to different proceduresor methods when producing such discs.

For example, various casino games, such as slot machines, may requirelittle from the player in terms of strategic decision-making or skill.For example, a player playing a slot machine at a casino might have alimited number of decisions to make—whether or not to pull a handle orpress a spin button, whether or not to increase or decrease a wageramount, whether or not to activate a particular payline, and so on.Further, such decisions may have little or no impact on the game resultthat is achieved, and thus may not be considered strategic decisions orskill-based decisions (though some players might confuse choosing aparticular bet amount as a skill-based decision). For example, arandomly-determined slot machine outcome of “Bar-Bar-Bar” may occurregardless of whether the player wagers a certain amount, and so on.Decision-making with respect to other casino games, such as roulette orkeno, may occur in a similar fashion—the decisions a player makes (e.g.,which numbers or groups of numbers to bet on in roulette; which numbersto select or an amount of numbers to select in keno) may determinewhether or not a player achieves a payout (e.g., if the numbers selectedmatch the drawn numbers), but may ultimately have no effect on arandomly-determined game result (e.g., the winning number of a roulettewheel spin, the winning numbers drawn in a keno game). Accordingly, insome embodiments, in association with non-skill-based casino games,automated sessions may produce game results that may be used fordetermining game disc content (e.g., media files indicating actual oralternative game results), and as described, the sessions may besimulated or otherwise executed in accordance with various parameters.Thus, various types of parameters may be applicable to the simulation orexecution of such non-skill-based games: (i) a type of game, includingprobability and payout structures for game results thereof; (ii) anumber of game plays to be executed and/or one or more conditions forterminating a session; (iii) wagering parameters (including either afixed wager amount per game play, or a variable wager amount per gameplay according to various rules, as described further herein); (iv) astarting credit balance; and so on. Of course, other parameters (e.g., anumber of active paylines, etc.) are contemplated.

However, it is understood that various other such casino games mayrequire further decisions from players, such as games that involveskill-based strategic decisions. For example, as is understood withrespect to various casino games including but not limited to Blackjackand video poker, a player may influence a game result by decidingwhether to hit or stand, discard one or more cards, and so on (e.g.,such games can be said to have a “perfect basic strategy” for hit/standdecisions, discarding cards, and so on). Accordingly, when simulating orotherwise executing one or more automated sessions in association withsuch games involving skill-based strategic decisions, various parametersmay be considered, such as any of the parameters described herein withrespect to non-skill-based games (e.g., wager amount per game play,termination conditions, etc.), as well as parameters that automaticallygovern such strategic decisions. For example, as will be describedfurther herein, during a simulated Blackjack game of a reference run, aplayer's hit/stand decisions may be made according to rules for perfectbasic strategy.

Thus, game discs may be offered in conjunction with various types ofcasino games, in both single-player and multiplayer formats, andassociated gaming sessions/contracts (e.g., reference sessions) may beexecuted according to various parameters.

In some embodiments, players may purchase a single-player roulette gamedisc (e.g., in DVD format). Such game discs may be associated with areference run comprising a plurality of gaming sessions simulated orotherwise executed according to various parameters. For example, onemillion sessions may be simulated by a computer device, and each of thesessions may be characterized by: (i) a particular roulette wheel (e.g.,the wheel comprises 38 numbers including “0” and “00”); (ii) aparticular starting credit balance (e.g., the balance starts at zerocredits); (iii) a particular wager amount per game play (e.g., $5 perspin); (iv) an indication of whether or not a credit balance is allowedto go negative, and if so, any limitations associated therewith (e.g., acredit balance may go negative without limitation); (v) a protocol forbetting (e.g., $5 bets will randomly be placed on either “red” or“black” each spin); and (vi) one or more conditions for terminating thesession (e.g., the session terminates after 50 spins of the roulettewheel). In this manner, a player may purchase such a roulette disc for aflat price, and view the disc, such that an animated roulette wheelspins and depicts a ball landing on various numbers, with bettingactivity and a credit balance potentially changing each spin. At the endof the disc, an amount of winnings (if any) may be indicated (e.g., by afinal credit balance may be output, though it should be noted that insome embodiments, if such a balance is negative, a player may owenothing other than the initial flat price paid for the disc).

It is understood that in a game such as roulette, the betting optionsavailable to a player in association with one or more game plays may bevery widely varied, in particular compared to a game such as slots. Forexample, when playing a slot machine, a player might elect to wager moreon a particular spin, or to activate a particular payline during onespin and not during another, and so on. Ultimately, however, it might besaid that players of a game like roulette may voluntarily swing orspread their bets in a much more volatile manner from spin to spin, asopposed to slot players, who have far fewer variables to manipulate. Forexample, roulette players might have 38 different individual numbers asbetting options for a particular spin, as well as combinations ofnumbers, columns, or other groups of numbers (e.g., odd vs. even, firsthalf vs. second half, and so on), not to mention the option ofincreasing or decreasing a wager amount.

Therefore, in some embodiments, it is imagined that pre-packaged slotmachine-themed game discs might offer game plays that is more consistentin nature; for example, such a slot machine-themed game disc might offerthe same amount of paylines and same wager amount per spin, and to aslot player, this may be thought of as an acceptable manner of play (itshould of course be noted, however, that the present inventioncontemplates offering game discs wherein wager amounts per game play ornumber of paylines activated of a slot machine vary within a particularrange from spin to spin). However, in order to accommodate the variedbetting tastes of players of a game such as roulette, it is contemplatedthat roulette-themed game discs might be offered in accordance with avariety of different protocols for betting. Such betting protocols maythen be considered as a parameter when generating game results inassociation with such game discs. A variety of such examples will now bedescribed.

In some embodiments, such roulette-themed game discs may offer bets thatmay vary from spin to spin. Thus, when game results associated with suchdiscs are generated, a computer device and/or gaming device beingutilized to (i) randomly determine and game result, and (ii) determine apayout amount based on the game result, may additionally operate torandomly determine a type of wager and/or wager amount in associationwith each game play, given various restrictions. For example, one ormore databases or tables in communication with such a computer deviceand/or gaming device may present types of wagers and/or wager amounts inassociation with various ranges of random numbers, in a manner similarto the probability table depicted by FIG. 15. In this manner, inassociation with each game play, such a computer device and/or gamingdevice may randomly determine a number, and then access such one or moretables or databases to determine a type of wager and/or wager amount.For example, for a first roulette spin, a random number may indicatethat a type of wager is to be “black” and that a wager amount is to be“$5,” though for a second roulette spin, a random number may indicatethat a type of wager is to be “red” and a wager amount is to be “$4.” Itshould be appreciated that such ranges of random numbers, types ofwagers available and wager amounts available may be structured in anymanner desired (e.g., such that only a small range of betting amountsare possible, such that it is more likely for one type of wager to beplaced than another, and so on).

In this manner, game results may be produced offering variations fromgame play to game play with respect to types of wagers or wager amountsplaced in a simulated game of roulette. For example, in one or moreembodiments, a roulette-themed game disc may be provided offering theplayer only a mix of “even money bets” (e.g., bets for which a playerwins $1 for every $1 wagered). For example, when generating game resultsin association with such a game disc, it may be randomly determined inadvance of each “spin” whether a wager will be placed on one of eitherred numbers, black numbers, even numbers, odd numbers, a first half ofnumbers or a second half of numbers (e.g., in association with each gameplay, a random number between one and six is determined, and the randomnumber indicates one of six even-money bets which will then be placed).A game result may then be determined (e.g., a random number between oneand 38 is generated to determine a winning number indicated by aroulette wheel), and then a payout may be determined based on the wagertype placed, wager amount placed and game result (e.g., if it wasdetermined to bet on “black,” and the number “13” is determined, theplayer may earn even money on his bet). In this manner, aroulette-themed game disc may be provided offering players varied evenmoney bets. In another example, a roulette-themed game disc may beoffered providing players with varied bets on particular numbers. In onespecific example, such a disc may offer $1 bets placed on fiverandomly-determined specific numbers (e.g., 12, 15, 20, 31, 33) inassociation with each game play (e.g., a computer device and/or gamingdevice determines five random numbers which will be wagered on, thenrandomly determines a winning number in association with each gameplay). In another example, a roulette-themed game disc may provide aplayer with varied mixed bets of a consistent wager amount inassociation with each game play. For example, for each game play, five$1 chips may be randomly placed on various betting locations (e.g., onechip is placed on “red,” another chip is placed on “15,” another chip isplaced on the pair of “34-35,” another chip is placed on the secondcolumn, and yet another chip is placed on “odd”). Thus, in one exampleof a manner in which one or more types of wagers may be randomly placedbefore a generation of a game result, a random number between one and153 may be determined (e.g., 153 representing a total number of allavailable roulette types available for a wheel featuring 38 numbersincluding “0” and “00”). Thus, a variety of types of roulette discsfeaturing varied wager types and/or wager amounts may be available so asto accommodate the differing tastes of players. Players may thenpurchase such game discs, which may present animations and/or associatedsound effects depicting a spinning roulette wheel and accompanyingroulette table, so as to learn of any winnings payable to players (e.g.,a final credit balance at the end of 50 spins). It should be noted that,in some senses, the betting styles of such discs may be thought of incategories (e.g., a disc that places bets on random specific numbersmight be thought of as “aggressive,” whereas a disc that places randomeven money bets might be thought of as “conservative”). Further, itshould also be noted that such methods for randomly determining suchwager types and/or wager amounts before an associated game result isgenerated and/or payout determined may comprise methods for storingand/or transmitting such data so as to facilitate an audit forfraudulent behavior. For example, if an electronic chronological log iskept that denotes, in a time-stamped sequence, (i) a randomly determinedwager type and/or wager amount, and (ii) a randomly determined gameresult, it may satisfy various parties (e.g., regulators, players) thatthe results of such game discs are produced in a fair manner (e.g., gameresults aren't “fixed” so as to purposefully select losing game resultsgiven a determined wager type and/or wager amount).

In other embodiments, players may be given an opportunity to purchaseroulette-themed game discs wherein wager types and/or wager amounts arefixed or standard from game-play to game play. For example, game discsmay be offered wherein a wager amount of $5 is consistently placed on“black” or on the second column. In another example, a player may selecta roulette disc offering 50 spins betting $1 each on the numbers 13, 15,18, 20, and 34—in such an example, it is envisioned that a player mightbrowse a plurality of such available combinations of numbers so as toselect a combination that a player feels a particular affinity toward(e.g., much like players choosing numbers of a lottery drawing, whocommonly play birthdates of family members). In yet another example, aroulette-themed game disc may be offered featuring a fixed pattern ofmixed bets (e.g., $1 on red, $1 on 34, etc.).

In some embodiments, multiplayer roulette-themed game discs may be madeavailable. For example, a four-player roulette disc may offer fourdifferent players various wager types and/or wager amounts for a givennumber of spins (or, as described, for an indeterminate number of spinsuntil some other termination condition is reached), and after the givennumber of spins transpires, a winning player and amount of winnings maybe determined. For example, four players may each wager $5 per spin onvarious combinations of particular numbers (or other bets), such that atthe end of the session, one player may have the highest final creditbalance, and therefore may be entitled to claim the balance. Forexample, four players may each wager $5 per spin on various combinationsof bets, and credit balances may be allowed to go negative, such thatafter 50 spins conclude (e.g., thus terminating an associated referencesession), a first player has a balance of −17 credits, a second playerhas a balance of 53 credits, a third player has a balance of 78 credits,and a fourth player has a balance of 89 credits (e.g., such that thefourth player may be entitled to claim 89 credits). Players viewing thedisc may monitor their progress by viewing the placement of bettingchips of various colors (each color associated with a particularplayer), viewing an animated roulette wheel and ball as winning numbersare determined, and viewing changes to credit balances associated witheach player (e.g., “Orange Credits,” “Green Credits,” “Red Credits,”“Blue Credits”). For example, player may be shown a display screensimilar to the one indicated by FIG. 28.

Referring now to FIG. 28, an example presentation 2800 of a four-player,roulette-themed game disc is depicted. Example player cards for arepresented keno drawing are depicted for respective “ORANGE,” “RED,”“GREEN,” and “BLUE” players. The displayed credit meters 2810, 2820,2830, and 2840 indicate the respective credit meter balances for each ofthe four players. The betting table 2870 indicates the possible betsthat may be made. No bets are depicted in the presentation 2800, but itwill be readily understood that an indication of particular wagers byrespective players may be presented (e.g., using media files asdescribed herein). The winning number 2850 indicates the last winningnumber from the simulated roulette spin. Wheel 2860 depicts one exampleof a roulette wheel and the last winning number. Of course, it will bereadily understood that a represented roulette wheel may be presented asspinning and an animated ball coming to rest at a particular number.Further, although only one number (“12”) is indicated, it will beunderstood that as much graphical detail may be provided as deemeddesirable and practicable.

Thus, in some embodiments, such a game disc may have been populated withmedia files depicting indications of game results associated with asimulated session of a reference run executed according to variousparameters, as described. It should be noted that in the case ofroulette, determining actual indications of game results may compriseidentifying one or more media files indicating exact wager types (e.g.,which numbers, combinations of numbers or other bets players made duringthe simulation) and/or wager amounts each player of the simulation mayhave placed. Accordingly, as it may be burdensome to store media filesdepicting a large number of such possible combinations (made even largerby the existence of a plurality of players, and even larger yet if suchwager types and/or wager amounts may vary randomly during thesimulation), it may be desirable to determine alternate indications ofsuch game results. For example, as described, alternate indications ofgame results may be selected such that each of the players arrives at apredetermined final session balance as indicated by the reference run.

Additionally, as described, when generating game results in accordancewith such a multiplayer roulette-themed game disc, the betting behavioror existence of a first player in a simulated session for generatinggame results may not affect the game results and/or payouts achieved bya second player (e.g., a randomly determined winning number of 32 willbe determined regardless of a number of players or how they bet).However, given various rules for determining a winning player or anamount of winnings such a winning player may be entitled to, theexistence and/or betting behavior of a plurality of players of asimulated session of roulette may have an effect on the average amountpaid out to players purchasing such game discs (e.g., and thus, mayaffect a retail price such discs may be offered for in order to maintainprofitability). For example, if a prize structure associated with such amultiplayer game disc awards a “winner-take-all” payout to a particularplayer, whereby the player not only wins a particular credit balance heis associated with, but also wins every other player's credit balance aswell, such a disc may be more expensive to provide than a multiplayergame disc that “pays the best player only” (e.g., the player wins onlyhis credit balance amount). Therefore, while the existence and/orbetting behavior of a player may not affect the game results achieved byanother player, the existence and/or betting behavior of a plurality ofplayers may influence a cost of offering such a disc (e.g., if a playerplaces certain kinds of bets, such as relatively risky bets associatedwith a high standard deviation, it may be more costly to provide such adisc in a winner-take-all format).

In some embodiments, wherein multiplayer roulette-themed game discsfeaturing varying wager types and/or wager amounts are offered, itshould be noted that such wagers may be placed on behalf of players in arandom, semi-random or pseudo-random fashion, though still reducing anoverall standard deviation associated with all wagers placed. Forexample, an example wherein a first player wagers $1 on “red,” and asecond player wagers $1 on “black” may be characterized by a first,lower standard deviation, whereas an example wherein a first playerwagers $1 on “red,” and a second player wagers $1 on “even” may becharacterized by a second, higher standard deviation. In the firstexample, a player might either break even or lose $2; in the secondexample, a player might either break even, lose $2, or win $2;therefore, a standard deviation associated with the second example mightbe higher, as the variance in payout amounts is greater. As described inApplicant's commonly-owned, co-pending U.S. application Ser. No.10/001,089, filed Nov. 2, 2001, entitled “GAMING DEVICE FOR A FLAT RATEPLAY SESSION AND METHOD OF OPERATING SAME”; and U.S. ProvisionalApplication No. 60/637,338, filed Dec. 17, 2004, entitled “GAMING DEVICEOFFERING A FLAT RATE PLAY SESSION AND METHODS THEREOF” (the entirety ofwhich have been incorporated by reference); when offering a flat-rategaming product, an increase in standard deviation may result in anincrease in the average amount paid out to players purchasing suchproducts (e.g., “contract cost”), and therefore it may be desirable toreduce standard deviation, such that products may be offered for lowerprices while maintaining profitability (e.g., because the player isplaying a flat price for the gambling product, the player's “downside”is potentially capped or limited, though an increase in standarddeviation associated with game play of the product may potentiallyincrease the player's “upside” in one or more payouts potentiallyavailable to a player, such that higher levels of standard deviation maynot be desired when offering such flat-rate gambling products).Accordingly, various methods of placing wagers on behalf of players of amultiplayer roulette-themed game disc are contemplated, such that thewagers are placed in a manner that reduces overall standard deviation.For example, a multiplayer roulette game disc may offer varied, mixedbets in association with two players. Thus, the bets may be placed onbehalf of each player such that they might “cancel each other out” orreduce standard deviation. For example, it may be randomly determinedthat a first player wagers $3 on black numbers for a particular spin;therefore, a software program of a computer device and/or gaming devicedescribed herein may automatically place on amount of chips (e.g., $3)on red numbers in association with a second player, so as to offset thefirst player's bet. Of course, each player may still have an equalopportunity to win as game results are generated randomly, so playersmay not mind such bets placed in an offsetting nature, so long as theyare placed honestly (e.g., before game results are determined). Itshould be noted that perhaps some players might enjoy such a roulettegame wherein they are pitted “against” another player by placingopposite or alternative bets.

In some embodiments, various features may be made available to playersof a roulette-themed game disc that may not commonly be available duringplay on a casino floor. For example, in one embodiment, players of amultiplayer roulette-themed disc may receive a “bonus spin” in an eventwhere no players place a winning bet on a particular spin (e.g., theplayers are allowed to re-post their wagers for free and the wheel spinsagain). In another example, if a player of a multiplayer disc is theonly winner at the table for three spins in a row, and the player winsmore than three bets on the third consecutive winning spin, the playermay receive a bonus payout.

It should be noted that a player and/or casino agent may inputparameters (and values thereof) desired for a session via many variousmeans (e.g., as alternatives to using one or more of a GD 315, POS 320or a CPD 325). For example, a kiosk, set top box of hotel room TV, a Webpage interface, a handheld casino device, a cellular telephone orlandline telephone may be used to input such information. Further, anyand all such means may be used by a player to input payment for asession or DVD. For example, a player selecting a DVD from a display inhis hotel room may use a set top box of the TV in his room to enter afinancial account identifier to provide payment for the DVD. In anotherembodiment, the price of the DVD may automatically be charged to theplayer's hotel room bill upon it being determined (e.g., during acleaning of his room) that the DVD as been taken from the display.

In some embodiments in which outcomes are generated at a GD by a casinoattendant (e.g., on behalf of a particular player), players may not bepresent to view the generation of outcomes at the GD. Accordingly,substantially lavish graphical presentations (or, for example, thespinning of mechanical reels) that typically accompany the generation ofoutcomes may not be necessary. In fact, in some embodiments, without aneed to entertain players at the time the outcomes are generated,graphic presentations or accompanying mechanical reel spins may eitherbe (i) expedited considerably (e.g., a video display screen outputs1,000 consecutive animations of spinning reels in the course of a fewminutes), (ii) presented in an alternate fashion (e.g., a display screensimultaneously depicts 1,000 symbol arrays), and/or (iii) abandonedaltogether (e.g., outcomes are generated and stored or output asdescribed elsewhere herein, but not presented in a conventional visualfashion).

Accordingly, a GD consistent with one or more embodiments may comprise aspecial “session outcome generation” mode accessible only by authorizedpersons (e.g., by casino attendants, and not by players). In such asession outcome generation mode, a GD may be capable of rapidlygenerating outcomes pursuant to a session characterized by certainparameters. For example, upon receiving instructions defining one ormore parameters (and values thereof of a session from a casinoattendant, a GD may use a random number generator to rapidly generate aplurality of random numbers, which may correlate to outcomes asspecified by a probability database, an exemplary tabular representationof which is depicted by FIG. 15. It should be appreciated that othermethods of generating outcomes are known in the art and need not bedetailed further herein.

As stated, in some embodiments, such a mode of operation may only bemade available to authorized persons. Thus, in some embodiments, aprocess of authorizing a GD to enter a session outcome generation mode(e.g., as performed by a GD 315 or CS 305) may comprise granting accessto such a mode of operation.

Access to such a mode of operation may be granted in a variety ofmanners. For example, in one or more embodiments, a GD may be configuredto receive an access code from a casino attendant.

For example, a casino attendant may actuate an input device of a GD(e.g., by pressing a button or an icon of a touch-sensitive displayscreen) requesting to access such a mode of operation. Upon receivingsuch an input, a GD or other device in communication with the GD (e.g.,CS 305) may be configured to output a request to receive an access codeor to cause such a request to be output to the player. The casinoattendant may then use an input device to enter an access code. Forexample, the casino attendant may enter a numeric or alphanumeric codevia a keypad or touch-sensitive display screen. The casino attendant mayhave received such a code when receiving an instruction to execute thesession at the GD (e.g., the access code may be provided to the casinoattendant via a CPD, along with an instruction to execute the session).In some embodiments, an access code may be provided to one or morecasino attendant for use in executing sessions on GDs and may not beunique to a particular session. In some embodiments, an access code maybe unique to a GD while in other embodiments it may not be. An accesscode may be determined or generated, for example, by CS 305.

In some embodiments, a process for authorizing a GD to enter a sessionoutcome generation mode may comprise determining whether a receivedaccess code is valid. For example, in one or more embodiments, adatabase (not shown) maintained by a GD or other device in communicationtherewith (e.g., CS 305) may contain a list of valid access codes, suchthat when an access code is received, it may be compared to the list todetermine whether or not it is valid. In some embodiments, access codesmay expire (e.g., upon one use, so as to prevent repeated fraudulentaccess), and accordingly, a device (e.g., a GD 315) may be configured towrite to such a database (e.g., so as to eliminate a record of an accesscode, such that it may not be considered valid if received thereafter orto update a status of an access code to reflect its use and/orexpiration).

Of course, various other methods of determining whether a user should begranted access to such a mode of operation are contemplated. Forexample, in one embodiment, a casino attendant desiring to access such asession outcome generation mode may simply insert or otherwise provide acard or identifier (e.g., in the form of a plastic magnetic stripe-basedcard similar to a player tracking card, a smart card, etc.). Uponreceiving the card or identifier, a device (e.g., GD) may determinewhether or not access should be granted to the session outcomegeneration mode. For example, a card reader device may read a magneticstripe to determine whether a valid access code is encoded thereon. Inanother example, a reader device may access a memory of a smart card todetermine whether a valid code is stored in memory thereon.

In other embodiments, authorized users may be granted access to such asession outcome generation mode via biometric means. For example, insome embodiments, a GD may comprise iris or retinal scanning means,voice detection means, and so on.

In still further embodiments, a GD may electronically receive a signalindicating that a session outcome generation mode is to be entered. Forexample, a server device (e.g., CS 305) may transmit an instruction orsignal to a GD 315 instructing that a session is to be executed. Such aninstruction may include an indication of the parameters of the session(and values thereof). In another embodiment, such an instruction orsignal may originate from a CPD 325 or other computing device. Forexample, a casino attendant stationed at a location within a casinoreceives a request from a player to execute a session on his behalf, andthe casino attendant uses a CPD or other computing device to transmit aninstruction or signal that instructs the GD to execute the session. Itshould be noted that, in some embodiments wherein such electronicinstructions or signals requesting the execution of a session arereceived, an accompanying access code or other means of authenticationor verification may or may not be required.

In some embodiments wherein a session may be executed by a casinoattendant or other authorized user interfacing with a GD, a programstored within a GD may, upon receiving a valid request to access asession outcome generation mode, cause various component devices (e.g.,output devices) to reconfigure, such that an authorized user mayfacilitate the execution of the session. For example, upon entering asession outcome generation mode, a display device (e.g., atouch-sensitive display screen) may be configured to output a menuscreen offering selectable options that would facilitate a user (e.g., acasino attendant) executing a session (e.g., on behalf of a particularplayer). FIG. 30 depicts an exemplary illustration such a menu screen.

Such selectable options may in essence allow a user to configureparameters associated with a session (i.e., to input values for eachrelevant parameter). For example, after entering a valid access code, acasino attendant may be presented with the menu screen and begin toconfigure various parameters of a session before having the GD executethe session, using a menu interface depicted by FIG. 30.

In some embodiments, a physical, non-electronic record of desiredsession parameters may be received from a player purchasing a session.For example, a player may have filled out a paper form, selecting (e.g.,marking with a writing instrument) various session parameter values(e.g., wager amount per game play, number of game plays, etc.). Inanother example, a casino attendant operating a computing device (e.g.,CPD 325) may issue a printed record of session parameters. In eithercase, a casino attendant may use such a physical record of sessionparameters for the purposes of entering desired session parameter valueswhen configuring a GD for executing a session.

For example, when instructed to execute a particular session (e.g.,identified by a unique session identifier), a casino attendant may beprovided with such a physical form indicating associated parameters andvalues thereof. The casino attendant may then locate (e.g., using GDdatabase 800) the one or more GDs on which the session is to beexecuted. In some embodiments, the one or more GDs may be identified bythe player purchasing the session (e.g., the player may have specified aparticular GD, a type of GD, a characteristic of a GD, etc.). Afterlocating the GD and accessing a session outcome generation mode, thecasino attendant may read from the paper form, and enter sessionparameter values using a menu interface.

Referring now to FIG. 29, illustrated therein are three distinctexamples 2905, 2910 and 2915, of tickets that may be printed by a GD,each ticket having an indication of a result of a session printedthereon. A ticket such as one of the three depicted in FIG. 29 may beprinted, for example, for auditing purposes, placed in a DVD jewel casefor a player to use to redeem a payment associated with the DVD, and/orused to provide an indication to a device (e.g., AS 310) of one or moreoutcomes of a session, the latter for purposes of creating a videorepresentation of the outcomes for recording onto a DVD. Such ticketsare referred to as “session results tickets” herein, as they typicallystore an indication of one or more results (e.g., payouts, sum ofpayouts) of a session.

Of course, a session results ticket may store an indication of otherinformation associated with a session as well, such as an indication ofone or more parameters defining a session and/or values thereof.Examples of such other information include, without limitation, (i) anend credit meter balance of the session; (ii) a price of the session;(iii) a beginning credit meter balance for the session; (iv) a number ofoutcomes generated for the session; (iv) a player (or players)associated with the session; (v) a casino attendant associated with thesession; (vi) a time and/or date at which the session was initiatedand/or completed; (vii) a gaming device at which the session wasconducted; (viii) a game for which the outcomes of the session weregenerated; (ix) a casino at which the ticket was generated and/or isredeemable; (x) a number of players associated with the session; and(xi) a unique session identifier associated with the ticket.

In one embodiment of a session results ticket that is printed for athree-reel slot machine game, each outcome of a three-reel slot machinegame, as well as corresponding payout information, appears as text. Onexample of such a ticket is illustrated as ticket 2915 in FIG. 29. Usingconventional TITO tickets (measuring 2.5″×6″; or approximately 6.35cm×15.24 cm) and TITO ticket printing technology, text regarding asubstantial number of outcomes may be printed on a ticket in thismanner. Several of such tickets may be used as necessary (e.g., aprogram stored within the memory of a GD instructs a printer device toprint 20 tickets, each with 50 game results of a 1,000 spin session).Exemplary paper tickets suitable for use according to such embodimentsare sold by Slot-Tickets.com™ of Memphis, Term. Of course, other methodsof printing an indication of outcomes of a session are contemplated. Forexample, rather than print an indication of a limited number of outcomeson a small, conventional ticket, a GD may comprise a roll of receiptpaper similar to those known and used in common retail systems, suchthat an indication of a substantially large number of outcomes may beprinted on one contiguous piece of paper (e.g., which may be torn off bya casino attendant or other authorized person after printing iscomplete). Such printing may occur at any time during or after theexecution of a session. A printed record of a result of a session maynot only be desired by players (who may view the record at a latertime), but also may be filed or stored by a casino or other entity forauditing purposes (e.g., regulations may require that such printedrecords exist).

In some embodiments, an authorized person (e.g., casino employee) mayspecify that a GD print a conventional “cashout ticket” indicating abalance of credits and/or currency at the conclusion of the execution ofa session.

In one or more embodiments, an indication of a result of a session maybe printed in an encoded or encrypted form or a form that is readable bya device but not easily discernable by a person. For example, ahigh-density barcode (e.g., see “video ticket” 2910) may encode a resultof a session. Such encoded data may then be used to render a videopresentation of outcomes, which may be viewed remotely by a player whohas purchased a DVD on which outcomes representative of the result ofthe session are recorded. For example, text, numerals or other symbolsor indicia stored within a session database (e.g., a series of outcomeidentifiers) may be encoded such that they are represented graphicallyby a barcode such as a high-density barcode.

In some embodiments, various parameters or settings of a GD and/orsession may be set to “default” (e.g., a GD automatically prints acashout ticket, video ticket and game result ticket upon the conclusionof an executed session). In some embodiments, an authorized person(e.g., a casino employee executing the session or causing the GD toexecute the session) may alter one or more of these parameters from thedefault sessions. In other embodiments, such an authorized person maynot be authorized to alter certain settings.

In some embodiments, an entity (e.g., an operator of AS 310) maydetermine session result data from a session results ticket. Forexample, if the session results ticket includes an indication of asession result encoded in barcode form, the session result may bedetermined by scanning a barcode of a session result ticket (e.g., thebar code of example session results ticket 2915). Such a barcode mayencode, for example, a session identifier, a series of outcomeidentifiers and one or more associated GD identifiers.

In one embodiment, a device (e.g., AS 310) may comprise software tocreate a video representation of outcomes for recording onto a DVD basedon session result data, such as may be determined from a session resultsticket. For example, AS 310 may receive session result data associatedwith a session in a manner such that AS 310 need not communicate via anelectronic network with a casino for purposes of obtaining such sessionresult data, but may rather be operable to receive session result datavia session result tickets. The AS 310 may be further operable toassemble video representations of outcomes based on such tickets andsupply such video representations (e.g., in the form of DVDs on whichsuch video representations are recorded) to players and/or casinos forsubsequent sale to players.

Referring now to FIG. 30, illustrated therein is a menu 3000 that may bepresented to a person (e.g., a player and/or casino attendant) forentering values of parameters to define a session. Such a menu may beutilized, for example, by a player who desires to order a DVD ofoutcomes. A player may define a session of outcomes to be generated viasuch a menu. In another example, such a menu may be utilized by a casinoattendant who is directing a gaming device to generate a plurality ofoutcomes for a session (either on behalf of a particular player or priorto any player ordering or purchasing such a session). The menu 3000 maybe displayed, for example, via a GD, kiosk, CPD, or other device.

As illustrated, in some embodiments a variety of parameters may beconfigured to define a session. For example, a wager amount per gameplay (actual or average) may be selected or indicated. In anotherexample, a duration of the session (e.g., in terms of number of gameplays, time, or ending event) may be selected or indicated. In yetanother example, a speed with which outcomes are to be generated, playedback and/or represented may be selected. In yet another example, anumber of payout combinations or particular payout combinations to beactive for the session may be selected or indicated. In yet anotherexample, an option for displaying the generated outcomes may be selected(e.g., such an option may only be available if the session is beingdefined by a casino attendant but not if it is being defined by aplayer, as this would spoil the player's enjoyment of subsequentlyviewing the outcomes via a DVD). In yet another example, an option forstoring the results may be selected (such an option may, in someembodiments, include several options for how (e.g., on what medium, onwhat device, as each is generated vs. once all are generated, etc.) theoutcomes are to be stored. In yet another example, an option forprinting a ticket or receipt indicative of the result of the session(e.g., a session results ticket) may be selected. Of course, other typesof parameters may be presented and defined (e.g., a GD or type of GD onwhich the session is to be executed, a game for which the outcomes areto be generated, a time at which the session is to be executed, astrategy to be employed in making decisions during game play, etc.).

Once a session is defined via the menu 3000, the person defining thesession may indicate a confirmation that the session is to be executed.Such a confirmation may, in some embodiments, cause a GD to immediatelyor substantially immediately execute the session in accordance with theparameter values indicated via the menu 3000. In other embodiments, sucha confirmation may cause the session to be scheduled or entered into aqueue, for subsequent execution by a GD (e.g., upon an availability ofan appropriate GD).

It should be understood that in some embodiments a value for aparticular parameter (e.g., number of game plays defining a session) maybe selected from a menu of pre-defined choices while in otherembodiments a value may be entered without selecting from pre-definedchoices (e.g., person can select any number of game plays or any numberwithin a pre-defined range of numbers).

For example, turning again to FIG. 30, the casino attendant may select awager amount of 75¢ per game play and a session or contract duration of1,000 game plays. The casino attendant may then select a speed setting.A speed setting may govern the rate at which outcomes are generatedduring the session. For example, if a casino attendant selects a “realtime” option, outcomes may be automatically generated at a substantiallyconventional pace (as they normally would in a standard mode ofoperation, taking several seconds to reveal each outcome). In anotherexample, a casino attendant may select an option that multiplies thestandard rate of outcome generation by some factor (e.g., outcomes willbe generated “ten times faster”). In yet another example, a casinoattendant may select an option that specifies a rate per unit time atwhich outcomes may be generated (e.g., “100 spins per minute”). In yetanother example, a casino attendant may select an option that“instantly” or substantially instantly generates results for all gameplays associated with a session. It should be understood that many ifnot all GDs possess the processing power to generate thousands if nothundreds of thousands of random numbers in as little as one second,facilitating the rapid or seemingly “instant” generation of such gameresults.

Various other parameters for a session may also be configured. Forexample, a casino attendant may specify one or more active paycombinations associated with a session (e.g., “BAR-BAR-BAR” is active,though “DOUBLE JACKPOT” is not).

Further, a casino attendant may configure various display optionsassociated with the execution of the session. As stated, without theneed to entertain a player (who may not be present for execution of oneor more game plays associated with a session), graphic presentations orother visual accompaniments commonly employed by GDs may either be (i)expedited considerably (e.g., a video display screen outputs 1,000consecutive animations of spinning reels in the course of a fewminutes), (ii) presented in an alternate fashion (e.g., a display screensimultaneously depicts 1,000 symbol arrays), and/or (iii) abandonedaltogether (e.g., outcomes are generated and stored or output asdescribed elsewhere herein, but not presented in a conventional visualfashion). Accordingly, a casino attendant may have an opportunity toselect various display options. For example, in one embodiment, a casinoattendant may select an option such that graphics, animations, sounds,the spinning of mechanical reels, etc. may be eliminated entirely. Inanother embodiment, a casino attendant may indicate that the GD shouldsimultaneously display a plurality of game results at the same time(e.g., 50 hands of 5-card stud poker are displayed at once). In anotherembodiment, a casino attendant may specify the amount of time that oneor more game results should be presented before another game result orset of game results are presented (e.g., simultaneously display 50outcomes of a 5-reel, video slot machine for 10 seconds, then displaythe next set of 50).

In further embodiments, a casino attendant may (i) select whether or notgame results are to be stored and/or transmitted electronically, and/or(ii) identify a manner in which game results are to be stored and/ortransmitted electronically. For example, by pressing an icon of atouch-sensitive display screen, a casino attendant may indicate that allgame results associated with a session should be stored electronicallyin a session database (e.g., such as session database 425 or activesessions database 435).

In one embodiment, a casino attendant may specify a location to whichgame results are to be transmitted electronically (e.g., CS 305 and/orAS 310, etc.). In one embodiment, a casino attendant may indicate thatgaming results are to be stored on a smart card currently inserted intoa reader device in communication with the GD generating the outcomes forthe session (e.g., such that a smart card may be associated with asession, and the results stored thereon such that they later may beaccessed for auditing, accounting or any other purposes). Such storageor transmission may occur at any time during or after the execution of asession (e.g., game results are individually stored as they aregenerated; game results are stored in RAM while they are beinggenerated, then written to ROM and erased from RAM; and so on).

In one example of executing a session in accordance with definedparameters, a number of game plays may then be executed in accordancewith the configured parameters. For example, 1,000 game plays of athree-reel slot machine at a wager amount of 75¢ per game play may beexecuted using an “instant” speed option, such that outcomes andassociated payout amounts are generated as rapidly as possible. Visualindications of such game results may then, if desired, be output via adisplay device (e.g., a casino attendant may optionally “scroll” throughscreens simultaneously depicting 100 outcomes each, after they have beengenerated). Further, the result of the session may be output asdescribed herein (e.g., a session results ticket may be printed and/oran indication of the session result may be transmitted to anotherdevice). It should be noted that, in some embodiments, the execution ofa plurality of game plays (i.e., generation of outcomes) may occur in asubstantially automatic manner. For example, once a person requests thata session be executed, the outcome generation for the session may occurwithout further input from the person. For example, it may not berequired for the person to actuate a “spin” button or other game playinitiation mechanism in association with each game play; rather, the GDmay be configured to execute game plays without interaction from theperson. Further, a GD may be configured to execute a game play withoutdeducting a wager amount from a credit balance, or by deducting a wageramount from a credit balance, even if the balance is “negative” or“zero,” and so on. Examples of some such methods are described incommonly-owned U.S. application Ser. No. 10/635,986, filed Aug. 7, 2003,entitled “SYSTEM AND METHOD FOR REMOTE AUTOMATED PLAY OF GAMINGDEVICES”; U.S. application Ser. No. 10/636,520, filed Aug. 7, 2003,entitled “SYSTEM AND METHOD FOR COMMUNICATING GAME SESSION INFORMATION”;and U.S. Pat. No. 6,012,983, filed Dec. 30, 1996, entitled “AUTOMATEDPLAY GAMING DEVICE”; the entirety of each are incorporated by referenceherein for all purposes.

Thus, in some embodiments, a person such as a casino attendant or playermay configure a GD such that it executes a session in accordance withone or more embodiments described herein. In other embodiments, a GD maybe configured to execute a session without receiving input from aperson.

As stated, in some embodiments of the present invention, a gaming devicemay be configured to execute a plurality of game plays on the player'sbehalf while the player is not present. Accordingly, as described, agaming device may be configured to operate in a “remote contract” modewherein a plurality of outcomes may be generated relatively rapidly.

Further, in some embodiments and as described with respect to FIG. 30, acasino attendant may (i) select whether or not game results are to beprinted (e.g., using a “TITO” device), and/or (ii) identify a manner inwhich game results are to be printed. For example, by pressing an iconof a touch-sensitive display screen, a casino attendant may indicatethat all game results associated with a session should be printed usinga TITO device. Further, a casino attendant may configure a manner inwhich such gaming results are to be printed.

Thus, in some embodiments, a GD may receive one or more signals orinstructions from a separate device (e.g., a server such as CS 305, asecond GD, a CPD, etc.), which may indicate (i) that a session should beexecuted, and (ii) parameters (and values thereof) associated with thesession. For example, a five-reel, nine-payline video slot machinelocated on the floor of a casino may receive a signal indicating thatthe device should generate 1,000 spins, with nine paylines activated and25¢ wagered per spin. The device may then execute the session asdescribed above (e.g., use the random number generator to generate theoutcomes) and output the session result data as described herein.Various methods of receiving such signals or instructions arecontemplated. For example, a communications port may receive atransmission via any communications protocol described herein (e.g., aserver sends such a signal to a GD using a BOB or other appropriateprotocol). Thus, in some embodiments, it may not be necessary for acasino attendant to interface with a GD to execute a session. In someembodiments, a casino attendant may later visit a GD on which a sessionhas been executed to retrieve printouts, session result data, etc.). Inother embodiments, session result data may be transmittedelectronically, as described herein, and a casino attendant need not beinvolved in the transmission of the session result data.

In some embodiments in which a player may request a session and a DVD ofthe session may be created in response thereto, a casino may receive arequest to execute a session at a first time, and execute the session ata later time. For example, so long as a player has agreed to such acondition, a casino may receive a request to execute a session from theplayer, and the session may be executed whenever the casino deems mostappropriate, so long as the execution occurs no later than a specifiedtime after the request was received (e.g., the casino has up to 48 hoursto execute the session).

Thus, in one or more embodiments, a casino may determine a level ofgaming device utilization before executing a session (whether thesession is executed on behalf of a particular player or not). Forexample, in one embodiment, a session may be executed when it isdetermined that there is sufficient capacity for the session. Forexample, it may be determined that enough slot machines located on thefloor of a casino are not currently being utilized, such that occupyingone slot machine for the purposes of facilitating a session will notresult in a shortfall of GD capacity that is deemed unacceptable by acasino. In one embodiment, GD utilization data may be stored in a GDdatabase, an exemplary data structure of which is depicted by FIG. 8.For example, a GD database may indicate a “device status” associatedwith a GD, which may describe whether the particular GD is currently “inuse” or “not in use.” A variety of methods of monitoring GDs to detectsuch utilization are contemplated (e.g., detecting game play activity,detecting the insertion of a player tracking card or contract card,detecting the presence of a player using a sensor device, monitoring GDswith video cameras, polling the GDs, etc.), such that in someembodiments, a server device (e.g., CS 305) may track GD utilization ina substantially automatic manner (e.g., a server detects use and writesto a centrally-stored GD database). In one embodiment, a percentageutilization metric may then be calculated with respect to all GDs withina casino (e.g., 37% of all machines are in use). Accordingly, in someembodiments, a session may or may not be executed depending on adetermined percentage utilization metric (e.g., if a percentageutilization metric is above a certain threshold, no sessions are to beexecuted). In one embodiment, historic GD utilization data may beconsidered when determining whether or not a session is to be executed(e.g., on average, slot machine utilization from 12 p.m. until 6 p.m. onWednesdays has been 23% at Casino A). In this manner, a casino caneffectively load balance the execution of sessions against theutilization of its casino floor, thus executing sessions at times whendoing so is preferable.

In some embodiments in which a session is executed on behalf of aparticular player and in response to a player request for the session, aplayer may request that a session be executed on a particular GD and/orGD of a particular type. Accordingly, in one embodiment, utilizationdata for GDs may be accessed (e.g., by a casino attendant using a CPD orby CS 305) to determine whether such a GD is available. If the desiredGD is available, the session may be executed (e.g., by dispatching acasino attendant to execute the session). In some embodiments, sessionmay only be executed if the desired GD has not been in use for somepredefined period of time (e.g., 30 minutes), and/or if it is a certaintime/date (e.g., no sessions may be executed on weekends or weeknightsbetween 7 and 11 p.m.). In some embodiments, a server or other computingdevice (e.g., CS 305) may continuously, substantially continuously,periodically or on another basis monitor the availability of one or moreGDs, and should a previously utilized GD that a player has requested fora session become available, the session may be executed. For example,(i) a casino attendant may be dispatched to the GD (e.g., a signal issent to a CPD, indicating the available GD's location, sessionparameters (and values thereof), and so on). In another example, asignal or instruction may be sent to the GD such that the session isexecuted. In some embodiments, a signal or instruction may be sent to aGD even when the GD is in use and the GD may be programmed to executethe session in accordance with the instruction at the first appropriatetime or simultaneously while allowing the use of the GD by a player in aconventional manner.

Referring now to FIG. 31, illustrated therein is an example embodiment3100 of a record of a database, storing an indication of payoutsdetermined by a gaming device for a session. As described, in someembodiments it may be unnecessary and/or undesirable to store anindication of the set of indicia representing each outcome of a session.However, it may be desirable to store an indication of payoutsdetermined for the session and, in some embodiments, the order in whichthe payouts were determined. For example, a probability database, payoutdatabase (or a database that combines features of a probability databaseand payout database, as described above with reference to FIG. 18), maybe used by a GD to determine a payout for each game play of a session.The GD or another device may then store an indication of each payoutand, in some embodiments such as the one illustrated in FIG. 31, theindication of the payouts. A device (e.g., AS 310) may then use thepayout data to create a video representation of the payouts. Forexample, the AS 310 may select, for each payout indicated in record3100, a media file that corresponds to the payout. For example, thefirst payout, which is indicated as “0”, the AS 310 may select a mediafile that comprises a set of indicia representing an outcome thatcorresponds to zero credits being won as a result of the game play.

The record 3100 includes a number of fields, including (i) a gamingdevice identifier field 3105 that stores an identifier of a GD on whichthe payouts were determined; (ii) a data type field 3110 that indicatesthe type of data stored in the record (e.g., in some embodimentsdifferent types of data, such as an indication of a set of indiciacomprising an outcome, may be stored); and (iii) an indication ofpayouts field 3115 that stores an indication of each payout generatedfor a session (each payout corresponding to a particular game play ofthe session) and the order in which the payouts were generated. Ofcourse, additional or different data may be stored in such a record. Forexample, an indication of a game (e.g., in addition to or in lieu of thegaming device identifier) for which the payouts were determined may bestored. In another example, an indication of a time and/or date of thesession and/or each individual payout may be stored. In yet anotherexample, an indication of a verification of the software used togenerate the payouts may be stored (e.g., a hash function technique maybe used to verify the authenticity and integrity of the software may beperformed at the beginning of each session and an indication of theresult of such an authentication process may be stored in the record).

In yet another example, an identifier that identifies a respectiveplayer associated with one or more of the individual payouts may bestored. For instance, one or more payouts may be associated with oneplayer, and one or more other payouts may be associated with a differentplayer.

Turning again to a description of a video presentation that may berecorded onto a DVD, in some embodiments one or more of several featuresmay additionally be made available to players when viewing a videopresentation. Some of these features are described below.

In some embodiments, a counter feature may inform players how manyoutcomes of a session have been depicted in prior segments of a videopresentation and/or how many outcomes remain in subsequent segments of avideo presentation. For example, at a particular frame of a videopresentation, an outcome or game play meter may display that there are322 (e.g., of 500) outcomes depicted in subsequent segments of the videopresentation. Such an outcome countdown meter may be a graphic overlaidonto frames or sections of frames of the video presentation.

In some embodiments, players may sort outcomes depicted in a videopresentation by various criteria and view the video presentationaccordingly. For example, players may select an option to “view allwinning results” or “view all losing” results. In another example, aplayer may select an option to “view all remaining results in order ofmy payouts, from highest to lowest.” Accordingly, in an embodimentwherein players view outcomes via a Web interface, a database or othermemory structure (e.g., a session database) may be accessed in responseto such requests (or may be utilized in creating video presentationsconfigurable based on such requests) and may thus comprise additionalfields for payout data, such that players requesting to view resultsbased on payout amounts may do so (e.g., such that a server may receivesuch a request, access a session database to determine an appropriatemedia file, and output the media file).

In some embodiments, players may be able to control the speed at which avideo presentation is output. For example, in one embodiment, a playermay view a video presentation recorded onto a DVD. The disc may containthree different media files associated with each game play number: onemedia file depicting a rendering of the game play result at a normalspeed, a second media file depicting a rendering of the game play resultat a rapid speed, and a third media file depicting a rendering of thegame play result at a slow speed. Thus, the player may, using an inputdevice of a DVD player (or personal computer), select a “fast-forward”option, such that one or more game play results of a session may then beoutput at a more rapid pace (e.g., upon receiving the input, the DVDplayer accesses the “rapid” version of each requested game play number).In an embodiment wherein players elect an option to review a pluralityof game play results at a time (e.g., without requiring further input,50 animations (each depicting a spin of a slot machine) are seen insequence), such a fast-forward and “slow motion” features may be useful(e.g., such that players may, for instance, rapidly scroll through setsof outcomes). In another example of a speed option that a player maycontrol, a player may select an option to enable or disable to“spinning” of animated reels, such that if the option is disabled, theplayer may see only the final resolution of the spin (e.g., theresulting symbol array) without a longer animated introduction.

Further, in some embodiments, players may be able to review videopresentations they have already viewed. For example, a player watching avideo presentation of a video poker session may select an option to“replay last hand” (such an input triggering a DVD to revert to aprevious chapter, a software application to replay the mostrecently-viewed animation, a server to access a media file inassociation with a particular game play number, and so on). Further,players may similarly review a plurality of game play results in such amanner (e.g., “replay last twenty spins”). In a further embodiment, apurchaser of a session may use an input device of a DVD player or DVDremote control to “rewind” a video presentation (such an embodiment maybe particularly effective when a player chooses a mode that displays aplurality of game play results in succession without requiring furtherinput).

In one or more embodiments, various triggers may cause the output of avideo presentation to be temporarily suspended or paused. For example, avideo presentation may be temporarily suspended or paused upon theoccurrence of a payout over a threshold amount of coins (e.g., payoutsover 100 coins). More specifically, in one example, a media file encodedon a DVD depicting a slot machine spin yielding a payout of 1,000 coinsmay contain an extended pause at the end of the file during which thereis no animation (or, alternately, added animation such as fireworks orother graphics may appear). In one embodiment, a media file depicting anoutcome corresponding to a payout of at least a certain magnitude may beof a longer duration, thus effectively including a pause or other imagedesigned to draw the player's attention to the payout. In one embodimentin which a pause is employed, an input may be required from a playerbefore the video presentation continues from a point at which it waspaused (e.g., such that the player must acknowledge the win). In thismanner, players may be less likely to miss the results that yieldedlarge payout amounts. In some embodiments, a pause may be employed afterthe display of each outcome.

In some embodiments, players may also optionally configure variousdisplay parameters for video presentations. Similarly to the displayparameters described with respect to FIG. 30 (e.g., wherein a casinoattendant may set display parameters before executing a session),purchasers of sessions may have the opportunity to select a variety ofdisplay options for viewing a video presentation based on the session,which display options may alter such parameters as (i) the number ofoutcomes displayed on the screen at once, (ii) the size of the outcomesdisplayed on the screen, (iii) the “skin,” appearance or theme ofvarious indicia (e.g., a player chooses an “ice age” theme as opposed toa “treasure hunt” theme), and so on.

In some embodiments, a game play result that has been used to generate avideo presentation may comprise a “bonus round” or other point in whicha decision from a player is typically required (e.g., a draw video pokergame typically requires a player to decide which cards to hold in agiven initial hand of cards). Commonly, some GDs offer entrance to abonus round upon the occurrence of a triggering condition, such as thereceipt of a bonus-triggering outcome (e.g., “Bonus-Bonus-Bonus”). Insome cases, such bonus rounds occurring on GDs may require no additionalinput or choice from a player. For example, a player may achieve abonus-triggering outcome, and accordingly a display screen may depict ananimated sequence that resolves in a number of additional “bonus”credits that the player has won. In some embodiments, suchnon-interactive bonus presentations may be incorporated into videopresentations (e.g., during a video presentation of a reeled slotmachine game, after the reels spin and depict a bonus-triggeringoutcome, the video presentation depicts an animated bonus sequence andreveals an amount of bonus credits).

In other cases, players interfacing with GDs on a casino floor may bepresented with several choices or options during a bonus round or otherpoint in a game (e.g., upon an initial hand of cards being dealt to aplayer in a video poker game). For example, upon achieving abonus-triggering outcome, several choices may be output to a player(e.g., a touch-screen depicts three boxes from which a player may chooseone). A bonus payout amount may then be based on the player's choice.

However, as described, some embodiments of the present inventioncomprise the execution of sessions of outcomes without the presence of aplayer to make such decisions. This may be handled in several manners.For example, in one embodiment, a player may authorize an agent (e.g.,casino attendant) to make such decisions on his behalf (e.g., such thatwhen executing a session, the agent may use a touch-sensitive displayscreen or other input device of a GD to make a selection in a bonus gameor to decide which cards of a hand of cards to hold and which todiscard). In another embodiment, a GD may be programmed such that, whenoperating in a session outcome generation mode (e.g., a DVD outcomegeneration mode), such selections (e.g., in a bonus round or other pointof a game play) may be made randomly or based on a predeterminedstrategy. For example, if there are three choices associated with abonus game, a GD may be programmed to generate a random number betweenone and three to determine an outcome/payout of the bonus round or toselect the left-most choice).

In some embodiments, a player may select a strategy as a value of aparameter in defining a session to be executed on behalf of the player.In some embodiments in which DVDs of sessions are mass produced prior toany request for a session being received from a player, a description ofa DVD available for purchase may include a description of a strategyused in executing the session, to make decisions on behalf of a player.This may be true for sessions of video poker games or other gamestypically involving player decisions. For example, a session for a drawvideo poker game may be executed using a perfect strategy ornear-perfect strategy in deciding which cards to hold for a giveninitial hand.

In some embodiments, video presentations that present such bonus roundsor other decisions may offer no interactivity to viewers. For example, avideo presentation depicts three boxes, one of which ishighlighted/selected during the video presentation without receivingplayer input, such that a payout amount is subsequently revealed. Inother embodiments, players may have a perceived influence over suchbonus round outcomes or other decisions (e.g., players may be given anopportunity to “select a box” using an input device, though the resultmay already have been determined before the player's selection and, forexample, assigned to all options the player may choose). It should againbe noted that such players watching video presentations at remotelocations may have no actual influence over associated game playresults, as any game play may have previously occurred (e.g., in a legaljurisdiction).

In some embodiments, a progressive “win” may occur during the executionof a session. Such a progressive win achieved during a session beingexecuted may be handled in a variety of manners.

For example, in one embodiment in which a session is being executed onbehalf of a particular player, the player may be instantly notified ofthe progressive win (e.g., the player is called before he is evenprovided with video presentation). In other embodiments, the player maynot be notified, but rather may learn of such a progressive win bywatching a video presentation.

In some embodiments, a pool of funds dedicated to paying out progressivewins may be decreased and/or reset immediately after a progressive “win”occurs during the execution of a session, or soon thereafter. However,in other embodiments, such a pool may not be decreased and/or resetuntil a player claims winnings.

In other embodiments, execution of sessions may not be permitted on GDsoffering progressive jackpots.

Progressive jackpot wins may be processed in a different manner inembodiments in which sessions are executed for a mass production processin which the sessions are not being executed on behalf of any particularplayer but are rather being produced to be later offered for sale. Suchembodiments may be referred to as pre-packaged DVD embodiments herein.For example, a pre-packaged DVD may comprise an outcome corresponding toa progressive win, though the disc may remain unsold for a period oftime. Accordingly, in some such embodiments, though a progressive “win”occurs once the session is executed, a progressive jackpot pool may notbe decreased until the DVD is sold, and/or until a player who eventuallypurchases the DVD attempts to redeem the DVD.

In some embodiments, various steps may be taken to prevent or discouragefraudulent purchase of pre-packaged DVDs. For example, because game playresults have already been generated at the time of purchase, a casinomay attempt to disguise the redemption values of such DVDs (e.g., suchthat players and casino employees may not figure out a way to “beat thesystem” by purchasing DVDs which they may know or suspect to correspondto large redemption values). For example, when generating a cashoutticket or otherwise outputting session result data associated with asession on which a resultant DVD will be based, no final session balancemay be indicated or may only be indicated in an encrypted form (e.g.,such that a casino attendant or other person with an opportunity to viewthe cashout ticket or other session result data may not be privy towhether the session has resulted in a relatively large aggregate).

Additional measures may be taken to prevent casino employees or otherpersons in a position of becoming aware or otherwise gaining access tosession result data associated with a session (whether it be a sessionfor a pre-packaged DVD or a session executed on behalf of a particularplayer). For example, in one embodiment, no session result ticket may beoutput. In another embodiment, a casino attendant administering asession or otherwise having an opportunity to gain access to sessionresult data may not be allowed to view game play results using a displayscreen of a GD or otherwise.

In some embodiments, a third party may administer the creation of videopresentations. For example, a casino attendant may execute a sessionusing a GD, such that afterwards a cashout ticket (that does notindicate a final session balance, but is printed nonetheless forauditing purposes) and a game video ticket are output. The casinoattendant may then provide the game video ticket to the third party. Thethird party (e.g., AS 500 or operator thereof) may then scan a barcodeof the game video ticket and produce a pre-packaged DVD based on theinformation encoded on the game video ticket. In this manner the finalsession balance associated with the DVD may not be known by a casino atthe time it is provided to a player. In some embodiments, at the time aDVD is given to the casino by the third party, a payout code mayadditionally be provided. For example, in some embodiments, playershaving purchased sessions or DVDs created based thereon may fail toclaim winnings (e.g., redeem the DVD for the redemption value) that theyare due. Accordingly, in some embodiments, a casino may be responsiblefor providing such payouts to players, though to prevent fraud, casinosmay not learn of a final session balance associated with a session untilafter an associated video presentation has been provided to a player.For example, thirty days after a DVD has been sold to a player, a casinomay provide the payout code to the third-party, which may inform thecasino of a final session balance due to the player.

In some embodiments, multiple players may remotely receive sessionresults generated by a GD (e.g., a GD located within casino premises).

For example, in some embodiments, a GD may be configured to periodicallygenerate batches of outcomes (e.g., 50 spins of a three-reel,three-payline video slot machine). Such batches of outcomes may bethought of as “scheduled sessions,” as players may be given anopportunity to purchase in advance the right to receive game playresults generated during such sessions. In some embodiments, suchscheduled sessions may (i) be scheduled to occur at predeterminedintervals (e.g., every five minutes), (ii) comprise a predeterminednumber of game plays (e.g., fifty game plays), and/or (iii) have asession identifier or session number associated therewith. Accordingly,a player may purchase or wager on a session occurring at a specific time(e.g., the player wagers on session number S-1905515, which occurs at5:15 p.m. tomorrow).

For example, players may visit a central location within a casino andindicate a desire to wager on one or more upcoming scheduled sessions.In some embodiments, players prepay a flat-rate price when wagering onan upcoming scheduled session. For example, when wagering on a session,a player may indicate a denomination of credits (e.g., $1.00, 25¢, 5¢,1¢, etc.). The denomination of credits and number of game plays withinthe scheduled session may determine a price associated with the session.For example, for a session of 50 slot machine spins at 50¢ per spin, aplayer might pre-pay a $25 price. However, for the same session, asecond player may indicate a credit denomination of 5¢, and therebyprepay only $2.50. Thus, when a 10-credit win occurs in the session, thefirst player may receive a payout of $5.00, whereas the second playermay receive a payout of only 50¢. In further embodiments, players mayplace wagers on several paylines of a slot machine session at once(thereby effectively increasing the number of game play results to bereceived, and therefore the price). For example, certain players of ascheduled session may benefit from having all three paylines “activated”(though such an activation would serve to increase the price), whereasother players may only wager on one payline (for a lower cost).

Accordingly, once a price is determined in association with the session,players may provide payment before the scheduled session begins. Forexample, a player may provide a payment to a casino attendant or kiosk.Once payment is received in association with one or more scheduledsessions, a player may watch, from a remote location, as game playresults are generated once the scheduled session begins.

In one embodiment, a casino may set aside one or more GDs of aparticular theme or game brand for scheduled sessions.” In one example,the GD is a five-reel, nine-payline video slot machine. The device maybe configured to automatically initiate fifty spins, each spin lastingabout three seconds, once every five minutes.

As such game play results are generated, they may be output such thatthey may be viewed by players remotely. A variety of methods ofoutputting such outcomes are contemplated. For example, in oneembodiment, a video feed may be taken from the slot machine, such thatthe feed may be broadcast over the Internet, or over a cable televisionchannel. In another embodiment, session result data may be output to acentrally accessible database, such that a Web site maintained by thecasino may be configured to rapidly interpret the data and translate thedata into visual presentations of outcomes that may be viewed by playersover the Internet. In another embodiment, stored audio and/or videofiles commonly output by the GD's display screen may be output to aserver device, such that players may access the files over the Internet.A variety of such methods of transmitting game play results from a GDsuch that associated audio and/or video files may be rendered over theInternet are contemplated.

When viewing such game play results, various status information may alsobe made available to players, such as (i) a number of coins or otherindication of value won by the player, (ii) a number of coins or otherindication of value won by other players who may have bet on the samescheduled session (e.g., though bet on different paylines), and so on.

In some embodiments, a GD configured to generate such game play resultsfor scheduled sessions (or for sessions as described elsewhere herein)may additionally be configured to generate game play results for localplayers interfacing with the GD. Several such examples are contemplated.

For example, in one or more embodiments, a GD may appear as a standardGD, and to a local user, may operate in a similar fashion to a GD thatis not also generating game play results for use in scheduled sessions.For example, a local user may utilize the GD in a conventional manner,providing wager amounts, executing game plays, viewing results, and soon. However, concomitantly, such a GD may generate game play results foruse in a scheduled session. For example, a processor of such a GD may beconfigured to generate local and session game play results at once. Inanother example, a program stored within the memory of the GD mayinstruct the GD to generate session game play results only when localgame play results are not being generated (e.g., each time there is a5-second lull between the initiation of game plays by a local user, theGD generates one or more outcomes for a session).

In some embodiments, session game play results may be output (e.g., by adisplay device) locally much as local results are. For example, in oneor more embodiments, a GD may be configured to utilize separate displayareas—one for local game play results, and one for session game playresults. For example, a GD may possess a “local” display screen as wellas a “session” display screen, the latter for depicting game playresults that remote players have wagered on.

Of course, it should be understood that in some embodiments, playersneed not view the execution of one or more game plays in associationwith such scheduled sessions in real-time. For example, game playassociated with a scheduled session may be executed before the sessionis scheduled to be “broadcast” to players who may have wagered on thesession (e.g., game play results are stored in a database).

Further, in some embodiments, a player may utilize computer software(e.g., of a home computer) to interpret and output results from aplurality of scheduled sessions that the player has wagered on. Forexample, such software may aggregate the results of multiple sessionswhich the player may not have had a chance to watch, such that theplayer may learn of wins, losses, a current balance, and so on.

Settlement of such scheduled sessions may occur in a manner similar tothose described previously with respect to sessions. For example, aplayer may return to a casino and present one or more of a receipt,scheduled session identifier or photo identification. A final balanceowed to the player may then be determined (e.g., a device such as POS320 may access session result data associated with the session, andbased on the wagers previously placed by the player, determine aredemption value for the session).

In some embodiments, players may be allowed to alter session parametersafter a session has been executed (but, e.g., prior to the playerviewing the results of the session). For example, in one embodiment, aplayer may return to a jurisdiction where gambling is legal (e.g.,return to a casino) and request that various parameters be altered. Forexample, a player may have originally purchased a session for 1,000spins of a slot machine at a wager amount of 25¢ per spin. After goinghome and watching 500 spins, the player may return to the casino andrequest that a wager amount per game play be increased to 50¢.Accordingly, it may be determined that the price associated with thesession may need to be altered as a result of the alteration to thewager amount parameter, such that the player may either need to make anadditional payment or be owed a refund. Further, the player may then beprovided with a new video presentation (e.g., such that elements of thevideo presentation effected by the player's changes to the parameters ofthe session (such as payout indications and changes to a credit balancemeter, in the present example) may be reflected). In another example, aplayer may return to a casino and forfeit a number of game playsassociated with an executed session. For example, a player may havepurchased a 1,000-spin session, and may have viewed only 500 spins ofthe video presentation based on the session. The player may then returnto the casino and forfeit the final 500 spins; in doing so, the playermay agree to forfeit any payouts associated with such spins, though hemay be provided with (i) payouts resulting from the first 500 spins,and/or (ii) a refund for the second 500 spins that the player did notreceive the benefit of. In some embodiments, players may be charged afee to forfeit a portion of a previously purchased session in such amanner.

In some embodiments, a first and second casino may be part of the same“session network.” Accordingly, a player may enter a first casino andpurchases a session and/or a DVD based on the session. The player maythen enter a second casino and (i) collect a redemption value associatedwith the session and/or DVD; and/or (ii) alter one or more parametersassociated with the session. Thus, in some embodiments, devices of afirst casino and second casino may communicate with one another (e.g.,so as to read from and/or write to one or more databases).

Some embodiments may not include an AS 310. For example, a server (e.g.,CS 305), GD (e.g., GD 310) and/or CPD 325 may be operable to performsteps described herein as primarily performed by AS 310.

In further embodiments, a Web site maintained by a casino property (orthird party) may function to (i) receive requests to view sessionresults (e.g., from remote players), (ii) retrieve session results(e.g., from a session database), and (iii) output a video presentationbased on the session results. Accordingly, in one or more embodiments,the creation of a video presentation may ultimately be performed as aWeb site interprets stored session result data and outputs animationsaccordingly. Such embodiments may be advantageous in that session resultdata may be output in a variety of manners (e.g., an outcome of“Bar-Bar-Orange” may just as easily be shown as any other outcome with acomparable payout amount, such that a variety of different game symbolappearances may be substituted for the “Bar” and “Orange” symbols), soas to accommodate players who request different visual themes associatedwith game plays executed as part of a session. Such an embodiment mayenable, for example, a player purchasing a session at a casino, loggingon to a home computer, and choosing several different slot machine“skins” for which to view session results.

It cannot be over-emphasized that the use of DVD or game disc as anexample media on which session result information may be recorded, toallow remote viewing of outcomes of the session, is intended as anexample only and should not be taken as limiting in any aspect. Thus,for example, although a sale of game disc (e.g., an encoded DVD) isdescribed in detail with reference to FIG. 22, a similar process may beperformed for a sale of a session in another remotely viewable form. Forexample, a sale of access to session results available online (e.g.,wherein a player may be provided with an activation code that allows theplayer to access a video presentation online) is also contemplated. Inanother example, a sale of a CD-ROM, VHS tape, floppy disc, flashmemory, memory stick, dedicated portable device for viewing videopresentations, and paper-based flip-through book that illustrates theoutcomes of a session may also be sold in a similar manner. In otherwords, the format or media via which the video presentation is providedto a player is not limited to a DVD or other type of disc. In anotherexample, the redemption of a DVD as described with reference to FIG. 27is not intended to limit the redemption of a session result to be via aDVD or disc form. For example, in one embodiment a player may provide aCD-ROM including a video presentation thereon and redeem the CD-ROM forthe redemption value associated with the session. In another example, aplayer having viewed a video presentation online may be provided with acode or other means of collecting a redemption value associated with thesession upon which the video presentation is based. Any practicablemethod of outputting a video presentation to a player such that a playermay purchase plurality of outcomes and view them remotely at theplayer's convenience is contemplated.

C. CONCLUSION

While various embodiments have been described herein, it should beunderstood that the scope of the present invention is not limited to theparticular embodiments explicitly described. Many other variations andembodiments would be understood by one of ordinary skill in the art uponreading the present description.

1. A method, comprising: determining a plurality of outcomes of aroulette game, in which a first outcome of the plurality of outcomes isassociated with a first wager, and in which a second outcome of theplurality of outcomes is associated with a second wager, in which thesecond wager is different than the first wager; storing an indication ofthe plurality of outcomes; and selling, after the last of the pluralityof outcomes has been generated, the plurality of outcomes to a player inexchange for a price.
 2. The method of claim 1, in which determining theplurality of outcomes comprises: generating the first outcome based onthe first wager; automatically determining the second wager; andgenerating the second outcome based on the second wager.
 3. The methodof claim 1, in which the first wager is associated with a first set ofnumbers and the second wager is associated with a second set of numbers.4. The method of claim 3, in which the first wager is associated with afirst wager amount and the second wager is associated with a secondwager amount that is different than the first wager amount.
 5. Themethod of claim 1, in which the first wager is associated with a firststrategy option, and the second wager is associated with a secondstrategy option.
 6. The method of claim 1, further comprising: selectingat least one of the first wager and the second wager at random.
 7. Themethod of claim 1, further comprising: determining a strategy option; inwhich determining the plurality of outcomes comprises: determining atleast one outcome of the plurality of outcomes based on the strategyoption.
 8. The method of claim 7, in which determining the strategyoption comprises: receiving an indication of the strategy option fromthe player.
 9. The method of claim 1, further comprising: receiving anindication of a preference of the player for a set of at least onenumber on which to wager.
 10. The method of claim 1, in whichdetermining the plurality of outcomes comprises: generating the secondoutcome on a gaming device operable to simulate outcomes for amultiplayer game.
 11. The method of claim 1, in which determining theplurality of outcomes comprises: executing a plurality of roulettespins.
 12. The method of claim 1, further comprising: determining thesecond wager based on the first wager.
 13. The method of claim 1, inwhich each of the first wager and the second wager are on a singleroulette spin.
 14. The method of claim 1, further comprising: selectingthe second wager from a plurality of possible wagers based on arespective overall standard deviation for each combination of the secondwager and each of the plurality of possible wagers.
 15. The method ofclaim 1, further comprising: determining a standard deviation of thefirst wager; determining a standard deviation of the second wager; andselecting the second wager over the first wager if the standarddeviation of the second wager is lower than the standard deviation ofthe first wager.
 16. The method of claim 1, further comprising:determining an amount of credit to wager on a single roulette spin;allocating a first portion of the amount of credit to the first wager;and allocating a second portion of the amount of credit to the secondwager.
 17. The method of claim 16, in which allocating the first portionis based on a standard deviation of the first wager.
 18. The method ofclaim 1, in which the first outcome is associated with a first playerand the second outcome is associated with a second player.
 19. Themethod of claim 18, further comprising: selecting the first wager forthe first player based on an overall standard deviation of placing thefirst wager and the second wager on a single roulette spin.
 20. Themethod of claim 1, further comprising: determining at least one of thefirst wager and the second wager based on a predetermined protocol forwagering.